Oxypod - Université Laval

Transcription

Oxypod
Rapport Version Finale
présenté à
Christian Gagné et Éric Poulin
par
Équipe 04 — Ulysse
matricule
nom
signature
910 082 448
Charles Ricard
910 101 383
Maxime Boucher Allard
909 160 573
Jean-François Melanson
910 121 682
Vincent Montminy
909 163 981
Stanislav Stefanovski
906 233 316
Jean-Patrick Boudreault
907 183 189
Pierre-Luc Belzile
Université Laval
15 avril 2011
Historique des versions
version
0
1
2
Finale
date
21 janvier 2011
4 février 2011
18 février 2011
18 mars 2011
15 avril 2011
description
création du document
description du projet: Chapitres 1 et 2
Besoins, objectifs et cahier des charges: Chapitre 3 et 4
Conceptualisation et analyse de faisabilité: Chapitre 5
Étude préliminaire et concept retenu: Chapitre 6 et 7
Table des matières
Table des figures
iv
Liste des tableaux
vi
1 Introduction
1
2 Description
2
3 Besoins et objectifs
3.1 Analyse des besoins . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.2 Analyse des objectifs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.3 Hiérarchisation des objectifs . . . . . . . . . . . . . . . . . . . . . . . . . . .
3
3
4
4
4 Cahier des charges
4.1 Module portable . . . . . . . . . . .
4.1.1 Fiabilité du module . . . . . .
4.1.2 Autonomie électrique . . . . .
4.1.3 Temps de recharge . . . . . .
4.1.4 Volume . . . . . . . . . . . .
4.1.5 Poids . . . . . . . . . . . . . .
4.2 Communication . . . . . . . . . . . .
4.2.1 Portée du transfert . . . . . .
4.2.2 Vitesse du transfert . . . . . .
4.2.3 Fiabilité des communications
4.2.4 Confidentialité des données .
4.3 Serveur et base de données . . . . . .
4.3.1 Performance du serveur . . .
4.3.2 Fiabilité du serveur . . . . . .
4.4 Interface . . . . . . . . . . . . . . . .
4.4.1 Facilité d’utilisation . . . . . .
4.4.2 Compatibilité logicielle . . . .
4.4.3 Complexité de développement
4.5 Coûts . . . . . . . . . . . . . . . . .
i
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
6
6
6
8
8
8
8
9
9
9
9
10
10
10
11
11
11
12
12
12
ii
TABLE DES MATIÈRES
.
.
.
.
12
13
13
13
5 Conceptualisation et analyse de faisabilité
5.1 Diagramme fonctionnel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5.2 Conceptualisation des solutions . . . . . . . . . . . . . . . . . . . . . . . . .
5.2.1 Module portable et communication . . . . . . . . . . . . . . . . . . .
5.2.1.1 Communiquer avec le serveur . . . . . . . . . . . . . . . . .
5.2.1.2 Sauvegarder localement les données du patient . . . . . . . .
5.2.1.3 Traiter les données en provenance du patient . . . . . . . .
5.2.1.4 Afficher localement l’état du module portable . . . . . . . .
5.2.1.5 Alimenter en électricité le module portable . . . . . . . . . .
5.2.1.6 Recharger la source d’alimentation électrique du module portable . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5.2.2 Serveur et base de données . . . . . . . . . . . . . . . . . . . . . . . .
5.2.2.1 Sauvegarder les données dans une base de données . . . . .
5.2.2.2 Gérer et transférer les données de l’ensemble des patients . .
5.2.3 Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5.2.3.1 Présenter l’information, permettre l’intervention à distance et
la configuration des modules . . . . . . . . . . . . . . . . . .
5.2.3.2 Choisir un langage de programmation . . . . . . . . . . . .
15
15
17
17
17
21
23
26
28
6 Étude préliminaire
6.1 Concepts retenus et plans de développement . . . . .
6.2 Concept 1 . . . . . . . . . . . . . . . . . . . . . . . .
6.2.1 Description . . . . . . . . . . . . . . . . . . .
6.2.2 Module : concept 1 . . . . . . . . . . . . . . .
6.2.3 Communication : Téléphonie cellulaire . . . .
6.2.4 Serveur : Amazon Relational Database Service
6.2.5 Interface : Java . . . . . . . . . . . . . . . . .
6.2.6 Coûts . . . . . . . . . . . . . . . . . . . . . .
6.3 Concept 2 . . . . . . . . . . . . . . . . . . . . . . . .
6.3.1 Description . . . . . . . . . . . . . . . . . . .
6.3.2 Module : concept 2 . . . . . . . . . . . . . . .
6.3.3 Communication : Wi-Fi . . . . . . . . . . . .
6.3.4 Serveur : Serveur local CybertronPC . . . . .
6.3.5 Interface : Python . . . . . . . . . . . . . . . .
6.3.6 Coûts : . . . . . . . . . . . . . . . . . . . . . .
6.4 Concept 3 . . . . . . . . . . . . . . . . . . . . . . . .
6.4.1 Description . . . . . . . . . . . . . . . . . . .
6.4.2 Module : concept 3 . . . . . . . . . . . . . . .
40
40
40
40
40
44
44
45
46
46
46
46
47
48
49
49
50
50
50
4.6
4.5.1 Coûts matériels . . . . .
4.5.2 Coûts d’opération . . . .
4.5.3 Coûts en main-d’oeuvre
Maison de la qualité . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
29
31
31
33
36
36
37
iii
TABLE DES MATIÈRES
6.5
6.6
6.7
6.8
6.4.3 Communication : Zigbee . . . . . . . . .
6.4.4 Serveur : Serveur local CybertronPC . .
6.4.5 Interface : Python . . . . . . . . . . . . .
6.4.6 Coûts : . . . . . . . . . . . . . . . . . . .
Concept 4 . . . . . . . . . . . . . . . . . . . . .
6.5.1 Description . . . . . . . . . . . . . . . .
6.5.2 Module : concept 4 . . . . . . . . . . . .
6.5.3 Communication : Wi-Fi . . . . . . . . .
6.5.4 Serveur : Location serveur distant dédié
6.5.5 Interface : JAVA . . . . . . . . . . . . .
6.5.6 Coûts : . . . . . . . . . . . . . . . . . .
Synthèse des résultats . . . . . . . . . . . . . .
Matrice de décision . . . . . . . . . . . . . . . .
Interprétation des résultats . . . . . . . . . . . .
7 Concept retenu
7.1 Présentation du concept retenu . . . .
7.1.1 Spécifications du concept retenu
7.1.1.1 Module Portable . . .
7.1.1.2 Communication . . . .
7.1.1.3 Serveur . . . . . . . .
7.1.1.4 Interface . . . . . . . .
7.1.2 Description des coûts . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
51
52
52
52
53
53
53
54
54
54
54
55
55
55
.
.
.
.
.
.
.
58
58
59
59
59
60
61
61
Bibliographie
63
A Liste des sigles et des acronymes
71
Table des figures
3.1
Organigramme des objectifs pour le projet Oxypod Phase 1 . . . . . . . . . .
5
4.1
Maison de la qualité du projet Oxypod - Phase 1 . . . . . . . . . . . . . . .
14
5.1
Diagramme fonctionnel du système Oxypod Phase 1 . . . . . . . . . . . . . .
16
7.1
Diagramme physique du concept retenu . . . . . . . . . . . . . . . . . . . . .
62
iv
Liste des tableaux
4.1
Cahier des charges du projet Oxypod phase 1 - Remarque : La valeur des
variables du tableau suivant ne sont pas limitées aux intervalles indiqués. Généralement, une valeur d’une variable entrainant un résultat supérieur à un
donne toujours un, sauf si un maximum est imposé à ce critère. Dans ce cas, le
concept doit être rejeté. De même, une valeur d’une variable entrainant un résultat négatif donne toujours zéro, sauf si un minimun est imposé à ce critère.
Dans ce cas, le concept doit être rejeté. . . . . . . . . . . . . . . . . . . . .
5.1
5.3
5.5
5.7
5.9
5.11
5.13
5.15
5.17
5.19
5.21
5.22
7
Aspects à considérer pour le module portable . . . . . . . . . . . . . . . . .
Analyse de faisabilité du système de communication . . . . . . . . . . . . . .
Analyse de faisabilité du stockage de données du module . . . . . . . . . . .
Analyse de faisabilité du traitement des données . . . . . . . . . . . . . . . .
Analyse de faisabilité de l’affichage des paramètres . . . . . . . . . . . . . . .
Analyse de faisabilité de l’alimentation du module . . . . . . . . . . . . . . .
Analyse de faisabilité de la recharge de la source d’énergie du modle portable
Aspects à considérer pour le serveur . . . . . . . . . . . . . . . . . . . . . . .
Analyse de faisabilité du stockage de données du serveur . . . . . . . . . . .
Analyse de faisabilité du transfert et de la gestion des données du serveur . .
Aspects à considérer pour l’interface . . . . . . . . . . . . . . . . . . . . . .
Analyse de faisabilité - Présenter l’information, permettre l’intervention à distance et la configuration des modules . . . . . . . . . . . . . . . . . . . . . .
5.24 Analyse de faisabilité du langage de programmation de l’interface . . . . . .
18
21
23
25
28
30
31
32
33
35
36
6.1
6.3
6.5
6.7
6.9
6.11
6.12
6.14
6.16
6.18
41
41
41
42
42
42
47
50
53
56
Plan d’étude pour le module portable . . . .
Plan d’étude pour la communication . . . .
Plan d’étude pour le serveur . . . . . . . . .
Plan d’étude pour l’interface . . . . . . . . .
Plan d’étude pour les coûts . . . . . . . . .
Composition du concept 1 - Projet Oxypod .
Composition du concept 2 - Projet Oxypod .
Composition du concept 3- Projet Oxypod .
Composition du concept 4- Projet Oxypod .
Synthèse de l’étude préliminaire des concepts
v
. .
. .
. .
. .
. .
. .
. .
. .
. .
du
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
projet Oxypod
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
38
39
LISTE DES TABLEAUX
6.20 Matrice de décision du projet Oxypod phase 1 . . . . . . . . . . . . . . . . .
vi
57
Chapitre 1
Introduction
Le phénomène du vieillissement de la population accentue le manque de personnel déjà
important dans le monde médical au Québec. Les gestionnaires des établissements de santé
doivent optimiser leurs ressources à l’aide des nouvelles technologies pour combler les besoins
de la population.
Afin d’améliorer la qualité et la fréquence des services fournis aux patients par les médecins, la clinique Oxygénia a mandaté le groupe d’ingénieurs Ulysse de l’Université Laval
pour réaliser une étude préliminaire visant le développement d’un nouveau système portable
d’oxygénation surveillant le patient en continu et contrôlable à distance par le médecin traitant. L’intention principale de ce nouvel appareil est donc de réduire les visites des patients
à la clinique et d’améliorer le rapport entre le patient et le médecin.
Le présent rapport expose les différents points de l’étude qui sont les besoins et objectifs,
le cahier des charges, la conceptualisation et l’analyse de faisabilité, l’étude préliminaire et
le concept retenu.
1
Chapitre 2
Description
La clinique Oxygénia à mandaté le groupe d’ingénieurs Ulysse pour concevoir et vérifier
la faisabilité d’un module portable de régulation de la saturation d’oxygène dans le sang
permettant des interventions médicales à distance. Lors de la phase 1, Oxygénia prévoit évaluer le concept retenu sur cent patients pour une durée d’un an. Des phases ultérieures de
développement prévoient l’inclusion de capteurs supplémentaires.
L’équipe Ulysse a comme tâches de concevoir le module, un serveur et une base de données
permettant l’échange d’information, de même que des interfaces de configuration et d’intervention. Le module doit lire les mesures des capteurs, recevoir puis transmettre la consigne
de débit à la vanne de régulation et finalement effectuer la régulation du taux de saturation
en oxygène. Il doit enregister les données des capteurs localement, en calculer les statistiques,
les transmettre au serveur et émettre des alarmes visuelles et sonores en cas de problème.
Finalement, le module doit être alimenté par une source d’énergie portable se rechargeant à
partir des réseaux électriques domestiques.
2
Chapitre 3
Besoins et objectifs
3.1
Analyse des besoins
Avec le mandat qu’a reçu notre équipe vient la responsabilité de répondre aux besoins
formulés par le client. Ces besoins sont axés sur quatre volets. Tout d’abord, il faut subvenir
aux besoins physiques directs du patient en assurant un taux d’oxygénation sanguin adéquat
et constant. De plus, le dispositif portable doit être d’une utilisation facile et conviviale et
s’harmoniser au rythme de vie des patients. La masse, le volume, l’autonomie et le temps de
recharge doivent pour cela être réduits au maximum afin d’assurer le confort physique des
patients.
Le second volet porte sur le suivi du patient à distance par son médecin traitant. Le transfert de données à distance doit s’effectuer par l’entremise d’un système de communication.
Pour faciliter l’utilisation du module, ce dernier doit s’accomplir dans un temps raisonnable
et sans trop de restrictions sur le point d’émission. D’autre part, puisque les données transférées sont importantes et confidentielles, aucune d’entre elles ne doit être corrompue lors de
la transmission ou encore obtenue par une tierce partie.
Le prochain volet repose sur l’ajustement du dosage et de l’algorithme du module par
l’utilisation des interfaces de configuration et d’intervation. Celles-ci doivent être simples
d’utilisation et compatibles avec n’importe quel système d’exploitation. Cependant, il est
prévu que la complexité du logiciel développé ne sera pas très important, étant donné qu’il
risque d’être modifié au cours les phases ultérieures du projet Oxypod.
En dernier lieu, l’aspect économique est n’est pas négligeable, car d’une part la clinique
ne dispose pas de fonds illimités et d’autre part parce que le système Oxypod doit être
concurrentiel sur le marché des appareils médicaux.
3
CHAPITRE 3. BESOINS ET OBJECTIFS
3.2
4
Analyse des objectifs
En évaluant de façon consciencieuse les principaux besoins du client, les quatre objectifs
principaux du projet Oxypod ont été identifés. Les sous-objectifs ajoutés accomplissent une
partie précise de chacun de ceux-ci. Voici donc la liste des objectifs et sous-objectifs du projet.
1. Optimiser la convivialité et le confort de l’utilisateur
(a) Minimiser le poids
(b) Minimiser le volume
(c) Minimiser le temps de recharge
(d) Assurer la fiabilité du module
(e) Maximiser l’autonomie électrique
2. Réduire les coûts
(a) Minimiser les coûts d’entretien
(b) Minimiser les coûts de main-d’oeuvre
(c) Minimiser les coûts matériels
3. Permettre aux médecins de suivre les patients à distance
(a) Maximiser la portée du module pour le transfert de données
(b) Maximiser la vitesse de transfert du module au serveur
(c) Assurer la fiabilité du transfert
(d) Assurer la confidentialité du transfert
4. Permettre un ajustement du dosage et la modification des algorithmes
(a) Faciliter l’utilisation de l’interface graphique
(b) Assurer la compatibilité de l’interface
(c) Réduire la complexité de développement
3.3
Hiérarchisation des objectifs
Ci-dessous, la figure 3.1 hiérarchise les objectifs devant être atteints. Les quatre objectifs
principaux sont représentés en haut de l’organigramme. Les sous-objectifs sont représentés
sous l’objectif principal dont ils découlent.
CHAPITRE 3. BESOINS ET OBJECTIFS
Figure 3.1 – Organigramme des objectifs pour le projet Oxypod Phase 1
5
Chapitre 4
Cahier des charges
Le cahiers des charges définit les critères que les objectifs et sous-objectifs devront atteindre. Leurs barèmes respectifs permettront d’évaluer les concepts concurrents du système
Oxypod lors de l’analyse préliminaire. Une pondération est attribuée à chacun des critères
pour représenter leur importance relative par rapport à l’ensemble du projet. Le tableau 4.1
présente la synthèse des critères, de leur pondération respective et des contraintes qui s’y
rattachent, le cas échéant.
4.1
Module portable
Le module portable de régulation est une partie très importante du projet Oxypod,
puisque c’est à travers ce dernier que les fonctions principales sont accomplies ; il effectue
la régulation du taux de saturation en oxygène, traite et sauvegarde les données du patient
localement. Une pondération de 37% lui est donc assignée.
4.1.1
Fiabilité du module
Le module portable doit pouvoir opérer longtemps sans défectuosité pour assurer correctement la régulation du taux sanguin de saturation en oxygène et ainsi assurer la qualité
de vie du patient. De même, cela évite les désagréments reliés à des réparations fréquentes
tant à la clinique qu’aux patients. Pour ces raisons, la pondération accordée à cet objectif
est de 8%. L’appareil est considéré défectueux lorsqu’une de ses composantes cesse de fonctionner. Par simplicité, la variable permettant d’évaluer la fiabilité du module portable est
M T BF = min(M T BF s), où M T BF s sont les temps moyens avant bris individuels des composantes du module portable. Un concept ayant M T BF égal ou supérieur à 85 000 heures
(environ 10 ans) sera considéré comme pleinement satisfaisant. Pour des valeurs inférieures,
le barème est M T BF/85000.
6
7
CHAPITRE 4. CAHIER DES CHARGES
Table 4.1 – Cahier des charges du projet Oxypod phase 1 Remarque : La valeur des variables du tableau suivant ne sont pas limitées
aux intervalles indiqués. Généralement, une valeur d’une variable entrainant un résultat supérieur à un donne toujours un, sauf si un maximum est
imposé à ce critère. Dans ce cas, le concept doit être rejeté. De même, une
valeur d’une variable entrainant un résultat négatif donne toujours zéro,
sauf si un minimun est imposé à ce critère. Dans ce cas, le concept doit
être rejeté.
Critères d’évaluation
4.1 Module portable
4.1.1 Fiabilité du module
4.1.2 Autonomie électrique [heures]
4.1.3 Temps de recharge [heures]
4.1.4 Volume [cm3]
4.1.5 Masse [kg]
4.2 Communication
4.2.2 Vitesse du transfert [kBps]
4.2.1 Portée du transfert [m]
4.2.3 Fiabilité des communications [%]
4.2.4 Confidentialité des données
Pond.
37%
8%
8%
5%
8%
8%
24%
5%
5%
7%
7%
4.3 Serveur
4.3.1 Performances [GHz]
4.3.2 Fiabilité du serveur [%]
4.4 Interface
4.4.1 Facilité d’utilisation
4.4.2 Compatibilité
14%
4%
10%
10%
4%
4%
2%
4.5 Coûts
4.5.1 Coûts matériels [k$]
4.5.2 Coûts d’opération [k$/an]
4.5.3 Coûts de main-d’oeuvre [k$/an]
15%
5%
5%
5%
Barème
M T BF/85000; [0,85000]
(AE − 4)/6; [4,10]
(6 − T R)/5.5; [0.5,6]
1 − (V /2500); [0/2500]
1 − (M/2.50); [0,2.5]
Min
Max
4
2500
2.5
(V − 200)/1800; [200,2000]
(log(R)−1)
; [10,30000]
(log(30000)−1)
(DS − 98)/2; [98,100]
0-Non sécuritaire
0.5-Partiel. sécuritaire
1-Hautement sécuritaire
(V − 2)/12; [2,14]
(DSS − 98)/2; [98,100]
N P/9; [0,9]
0- Mauvaise
0.5- Passable
1- Excellente
0-Élevée
0.5-Moyenne
1-Faible
(200 − CM )/200; [0,200]
(50 − CO)/50; [0,50]
(200 − CM )/200; [0,200]
200
50
200
4.1.2
8
Autonomie électrique
Étant donné que le système de régulation en oxygène est portable, il est nécessaire que
son alimentation électrique soit assurée pour une durée prédéterminée pour permettre au
patient de vaquer à ses occupations et de se déplacer sans risque. De même, une autonomie
importante diminue la fréquence des recharges. Ces considérations par rapport à la qualité
de vie font en sorte que la pondération accordée à l’autonomie de l’alimentation électrique
est de 8%. Un concept permettant au patient d’effectuer un quart de travail complet, soit
environ dix heures, sera jugé pleinement satisfaisant, alors qu’un autre ne permettant que
quatre heures d’autonomie sera rejeté. Entre ces valeurs, le barème est (H − 4)/6 où H est
l’autonomie du module portable en heures.
4.1.3
Temps de recharge
Un autre aspect important de la convivialité du module portable est le temps de recharge
de la source d’énergie électrique. En effet, le patient ne doit pas être immobilisé longtemps
en raison de la recharge de la batterie. Ce critère a une influence de second ordre sur la
convivialité, c’est pourquoi une pondération de 5% lui a été accordée. Une durée de recharge
d’une demi-heure satisfait entièrement ce critère, car elle correspond à une période d’immobilisation tolérable pendant une journée normale. Toutefois, un temps supérieur à une nuit
de sommeil, soit six heures, sera considéré comme inadéquat et se verra attribué une note de
zéro. Entre ces valeurs, le barème pour la durée de recharge D en heures est (6 − D)/5.5.
4.1.4
Volume
Le volume du module portable a un impact sur la convivialité d’utilisation de celui-ci et
sa portabilité. Un module trop volumineux sera encombrant et son transport peu pratique.
C’est pourquoi une pondération de 8% lui a été accordée, puisque ce critère a un impact
direct sur le confort de l’utilisateur. Un concept ayant un volume supérieur à 2500 cm3 sera
rejeté, car il ne répond pas à une exigence du client. Pour des valeurs de volume V exprimées
en cm3, le barème est 1 − V /2500.
4.1.5
Poids
La masse du module portable est un aspect important du confort de l’utilisateur du
module portable. Le module devant être transporté constamment, une masse élevée peut
nuire causer de la fatigue chez le patient atteint de troubles respiratoires. C’est pour cette
raison que la pondération accordée à ce critère est de 8%. Le barème servant à évaluer ce
critère se base sur la masse M du module en kilogramme et est 1 − M/2.50. Un concept
ayant une masse supérieure à 2.5 kg sera rejeté, car il ne répond pas à l’exigence du client.
4.2
9
Communication
Le système de communication entre le serveur et le module représente une grosse partie
du projet Oxypod. En effet, c’est lui qui permet au médecin de suivre le patient à distance,
et d’assurer le transfert instantanné des données enregistrées vers la base de données lorsqu’à
domicile et ce, sans fil. Il se voit donc assigner une pondération de 24%.
4.2.1
Portée du transfert
La portée de transmission sans fil des modules portables vers le serveur est un facteur
à considérer. Une portée de transfert élevée enlève des restrictions sur les déplacements du
patient, un facteur d’importance moyenne vis-à-vis de la convivialité. Ces raisons font en sorte
que la pondération accordée à ce critère est de 5%. La transmission sans fil peut s’effectuer
sur des échelles de distances très différentes. Avoir une portée de transmission élevée est
un plus, mais pas nécessairement de beaucoup par rapport à une portée moindre. C’est
pour cette raison qu’une échelle logarithmique a été choisie pour le barème. Un concept ne
garantissant pas un transfert sans fil peu importe l’endroit où le patient se situe dans sa
résidence, soit environ dix mètres, sera jugé insatisfaisant. Un autre concept permettant le
transfert dans une communauté urbaine très élargie, soit 30 000 m, sera considéré comme
remplissant pleinement ce critère. Entre ces valeurs, le barème pour la portée du signalest
(log(R) − 1)/(log(30000) − 1) où R est la porté en mètres.
4.2.2
Vitesse du transfert
La vitesse de transfert entre le module portable et le serveur influence également la convivialité d’utilisation du système Oxypod, puisqu’il a une influence directe sur le temps nécessaire que doit passer le patient dans le rayon où la communication sans fil peut s’effectuer. Ce
critère a une influence moyenne sur la convivialité, ce que reflète la pondération de 5% qui lui
a été attribuée. Une connexion inférieure à 200 Kbps sera jugée insuffisante (note de 0), alors
qu’une connexion de 2Mbps ou supérieure sera considérée comme répondant parfaitement à
ce critère. Entre ces valeurs, le barème pour la vitesse de transfert est (V − 200)/(1800) où
V est en kilobits par seconde (Kbps).
4.2.3
Fiabilité des communications
Le réseau de communication doit être en mesure de transporter les informations des
patients venant des modules portables et de permettre l’accès à la base de données aux
médecins. Il est important que ces derniers aient accès aux informations des patients en tout
temps afin d’effectuer un suivi adéquat. De même, il faut que les médecins aient accès à la base
de données lors des rendez-vous avec les patients, car ceux-ci sont souvent difficiles à déplacer.
C’est pour ces raisons que la pondération attribuée à ce critère est de 7%. Le barème servant
à évaluer celui-ci se base sur la disponibilité stationnaire du réseau de communication, qui
mesure le temps où les données peuvent être échangées. Un concept garantissant un transport
10
sans interruption sera considéré comme satisfaisant pleinement ce critère, tandis qu’un autre
disponible seulement 98% du temps et moins sera jugé insuffisant (note de 0). Le barème
pour la fiabilité du transfert est (DSC − 98)/2 où DSC est la disponibilité stationnaire du
réseau de communication.
4.2.4
Confidentialité des données
La confidentialité des informations médicales doit être irréprochable, étant donné la nature
personnelle de celles-ci. En outre, la divulgation de ces informations peut porter préjudice
à l’individu concerné. Cette nécessité se traduit, entre autres choses, par l’obligation du
secret professionnel chez les médecins. Les communications entre le module portable et le
serveur doivent répondre aux mêmes exigences. C’est pour cette raison qu’une pondération
de 7% a été accordée à ce critère. Un mode de communication non sécurisable sera jugé non
sécuritaire (note de 0), un mode de communication sécurisé mais nécessitant des précautions
supplémentaires sera considéré comme partiellement sécuritaire (note de 0.5) alors qu’un
mode de communication sécurisé avec un encryptage intrinsèquement très fort sera considéré
comme hautement sécuritaire (note de 1).
4.3
Serveur et base de données
Les informations stockées dans les modules portables doivent être transmises vers un serveur contenant une base de données, qui sert d’intermédiaires entre le module portable et
l’interface du médecin. Le serveur doit de plus transmettre les consignes du taux d’oxygène
prescrites et tout autre paramètre permettant l’ajustement du module de régulation à distance. Cette section est légèrement moins importante que la première, puisqu’elle n’influence
pas directement la santé du patient. Cependant, elle est néanmoins essentielle pour permettre
un suivi médical à distance efficace. C’est pour cette raison que sa pondération représente
14% du projet.
4.3.1
Performance du serveur
La vitesse du processeur permet d’évaluer la performance du serveur et permettra d’évaluer sa capacité à envoyer, recevoir et traiter les informations et de savoir s’il pourra le faire
dans des délais raisonnables. Dans le cadre de la phase 1, cette caractéristique a une importance moindre, parce que la nature des données est peu complexe (essentiellement du texte)
et que le volume à traiter de celles-ci est relativement faible. Cependant, un puissance substantielle serait appréciable pour répondre à une augmentation du nombre de patients. C’est
pour ces raisons qu’une importance relative de 4% lui est accordée. Pour le barème, la formule
est (V − 2)/12. La variable V est la somme des fréquences individuelles des processeurs en
GHz.
4.3.2
11
Fiabilité du serveur
La fiabilité du serveur se traduit par sa capacité à continuer à enregistrer, à ne pas perdre
les informations des patients et à permettre l’accès à la base de données aux médecins. Ce
critère est essentiel pour effectuer un suivi médical efficace. C’est pour ces raisons que la
pondération accordée à ce critère est de 10%. Un serveur ayant une disponibilité stationnaire
de 98% au cours de l’année sera jugée insatisfaisant (note de 0), alors qu’une disponibilité
stationnaire de 100% sera considérée comme remplissant pleinement le critère. Soit DSS,
la disponibilité stationnaire du serveur, le barème est (DSS − 98)/2. Puisque le taux de
disponibilité jugé insatisfaisant est fixé à 98%, le système assure alors accès continu au serveur
358 jours dans une année.
4.4
4.4.1
Interface
Facilité d’utilisation
L’interface se doit d’être facile d’utilisation pour permettre un accès rapide et intuitif aux
informations contenues dans la base de données, de même que pour permettre aux médecins
de modifier le programme des modules portables sans qu’il y ait de danger de fausses manipulations. Il s’agit donc d’un aspect augmentant la convivialité d’utilisation du système
Oxypod, mais qui n’influence pas directement la santé du patient. C’est pour cette raison
qu’une pondération de 4% a été accordée à ce critère. L’évaluation de la convivialité est
complexe en l’absence de rétroaction de la part d’utilisateur. La méthode des neuf heuristiques de Nielsen et Molich pour l’évaluation des interfaces homme-machine [32]. Les points
à considérer sont les suivants lors d’un "dialogue humain-machine" :
1. Dialogue simple et naturel : Les ordres correspondent aux tâches à effectuer
2. Language approprié à l’utilisateur : Utiliser des mots et des concepts appartenant
à l’univers de l’utilisateur (dans le cas présent, des médecins).
3. Minimiser l’utilisation de la mémoire de l’utilisateur : Ne pas demander à l’utilisateur de se remémorer de l’information d’une action à l’autre. Laisser l’information
à l’écran jusqu’à ce qu’elle ne soit plus nécessaire
4. Être constant : L’utilisateur devrait pouvoir utiliser des séquences d’actions apprises
à un endroit pour atteindre des résultats similaires à d’autres endroits.
5. Assurer une rétroaction : Permettre aux utilisateurs de voir les effets que leurs
actions ont sur le système.
6. Fournir des portes de sorties facilement identifiables : Donne à l’utilisateur un
moyen de quitter une partie du système qui ne l’intéresse pas sans rien endommager.
7. Fournir des raccourcis : Pour éviter un dialogue long et fastidieux.
8. Avoir de bons messages d’erreur : Laisser savoir à l’utilisateur quel est le problème
et comment le régler.
12
9. Prévenir les erreurs : Se demander s’il est possible de prévenir les erreurs avant
qu’elles ne se produisent.
Soit N P le nombre de points satisfaits, alors le barème pour ce critère est : N P/9.
4.4.2
Compatibilité logicielle
L’interface doit impérativement être compatible avec le matériel informatique des médecins traitants afin de leur permettre de suivre leurs patients et de modifier le programme
des modules portables. Advenant une incompatibilité, l’interface risque de ne pas fonctionner correctement ou de ne pas fonctionner du tout. De plus, une compatibilité faible risque
d’entrainer l’acquisition de matériel informatique aux cliniques utilisant le système Oxypod,
ce qui est à éviter. Quoique ce critère ne soit pas critique, il est néanmoins important, ce que
reflète la pondération de 4% qui lui a été accordée. Le barème utilisé pour évaluer celui-ci
est le degré de compatibilité logicielle de l’interface avec les systèmes d’exploitation présents
sur le marché. Un concept compatible avec tous les systèmes d’exploitation, récents comme
anciens, sera considéré comme excellent (note de 1), tandis qu’une interface compatible seulement avec les plus récents sera jugée comme passable (note de 0.5), tandis qu’une autre ne
fonctionnant qu’avec un seul système d’exploitation sera jugée mauvaise (note de 0).
4.4.3
Complexité de développement
Il existe plusieurs technologies ainsi que divers langages adaptés à la création de logiciels
et d’interfaces comme celle qui sera développée dans le cadre de la première phase du projet
Oxypod. Étant donné que ce critère n’évalue pas une fonctionnalité essentielle au projet Oxypod, puisqu’elle influence la tâche du programmeur-analyste son importance est relativement
mineure et sa pondération de 2% le reflète. La complexité de développement et de maintenance est principalement dépendante du niveau d’abstraction du langage de programmation
utilisé, des interfaces de programmation et des cadres d’applications. Le barème de ce critère
est le suivant : un concept permettant un développement rapide sera jugé de complexité faible
(note de 1) alors qu’un autre ayant un développement long sera jugée de complexité élevée
(note de 0). Si le temps de développement est moyen, la complexité sera jugée moyenne (note
de 0.5).
4.5
4.5.1
Coûts
Coûts matériels
Les coûts matériels du projet Oxypod doivent également être pris en compte, car des
coûts élevés pourraient nuire à une commercialisation future du système. C’est pour cette
raison qu’une pondération de 5% a été accordée à ce critère. Les coûts matériels se divisent
principalement en deux aspects.Ceux associés aux modules portables et au serveur. Les coûts
13
matériels sont estimés à partir de considérations techniques. L’appareil portable doit contenir un système de traitement, de stockage, de communication et d’affichage, pour un coût
approximatif maximal évalué à 1000$ par unité. Le serveur de la base de données doit, quant
à lui, contenir un système de stockage, de traitement, de même qu’un système de communication avec l’interface, pour un coût approximatif maximal évalué à 100 000$. Le barème
d’évaluation pour les coûts matériels CM est (200000 − C)/200000. Un concept ayant des
coûts matériels supérieurs à 200 000$ sera considéré comme trop dispendieux sera rejeté.
4.5.2
Coûts d’opération
Les coûts d’entretien représentent une charge monétaire récurrente pour les cliniques
de santé et les patients qui utiliseront le système Oxypod. La compétitivité du système
Oxypod sur le marché peut diminuer si ceux-ci sont trop élevés. C’est pour cette raison
qu’une pondération de 5% a été accordée à ce critère. Le barème, pour le coût d’entretien
annuel CE du système Oxypod en dollars est (50,000 − CO)/50,000. Un concept ayant un
coût d’entretien annuel dépassant 50 000$ sera rejeté.
4.5.3
Coûts en main-d’oeuvre
Étant donné l’envergure du projet et sa nature technologique, les coûts de main-d’œuvre
peuvent facilement devenir considérables. C’est pourquoi il a été jugé pertinent d’accorder
une pondération de 5% à ce critère. Le barème pour ce critère, avec CM , le coût de la main
d’œuvre en dollars, est (200000 − CO)/200000. Un concept ayant des coûts de main-d’œuvre
supérieurs à 200 000$ sera rejeté.
4.6
Maison de la qualité
La maison de la qualité est un outil de gestion de projet qui permet de lier les objectifs,
les critères et les contraintes. La figure 4.1 présente la maison de la qualité du projet.
Figure 4.1 – Maison de la qualité du projet Oxypod - Phase 1
14
Chapitre 5
Conceptualisation et analyse de
faisabilité
Dans ce chapitres, des sous-concepts sont proposés afin répondre aux sous-problèmes
du projet Oxypod. Une brève analyse de faisabilité permet ensuite de séparer les concepts
prometteurs de ceux inappropriés. Les concepts retenus serviront à la production de concepts
globaux qui seront étudiés plus en détails dans lors de l’étude préliminaire (chapitre 6).
5.1
Diagramme fonctionnel
La figure 5.1 représente le diagramme fonctionnel du projet Oxypod. Celui-ci met en
relation les différentes fonctionnalités du système et permet d’avoir une vision globale de la
problématique. Les sous-problèmes du projet ont été déterminés à partir de l’analyse de ce
diagramme fonctionnel. Ceux-ci sont les suivants :
Pour le module portable :
1. Recharger la source d’alimentation électrique du module portable
2. Alimenter en électricité le module portable
3. Traiter les données en provenance du patient
4. Sauvegarder localement les données du patient
5. Afficher localement l’état du module portable
6. Communiquer avec le serveur
Pour le serveur et la base de données :
1. Gérer et transférer les données de l’ensemble des patients
2. Sauvegarder les données dans une base de données
Pour l’interface :
1. Présenter l’information, permettre l’intervention à distance et la configuration des modules
15
CHAPITRE 5. CONCEPTUALISATION ET ANALYSE DE FAISABILITÉ
16
2. Choisir un langage de programmation pour l’interface
La figure 5.1 permet également de voir les relations entre les intrants et les extrants
principaux. Le système Oxypod sert donc à convertir les données biologiques du patient
provenant des capteurs en un taux constant de saturation en oxygène dans le sang chez ce
dernier, grâce aux connaissances professionnelles du médecin soignant. Il permet également
de produire une base de données contenant l’historique de la santé de tous les patients.
Figure 5.1 – Diagramme fonctionnel du système Oxypod Phase 1
5.2
17
Conceptualisation des solutions
Les concepts de solutions aux sous-problèmes identifiés précédemment sont développés
dans cette section. Chaque solution est évaluée sommairement pour vérifier que les critères
énoncés dans le chapitre 4 sont minimalements atteints. Ces solutions serviront à produire
des concepts globaux pour le système Oxypod.
Remarque : Pour ce qui est des coûts, du volume et du poids. Il seulement vérifiés que
les solutions individuelles ne dépassent pas les limites qui ont été fixées pour les concepts
globaux. L’étude détaillée de ces critères est effectuée au chapire 6
5.2.1
Module portable et communication
Le module portable constitue la partie centrale du projet (61% de la pondération totale,
soit 37% pour le module portable et 24% pour la communication qui doit se faire entre ce
dernier et le serveur). Cette section élabore des concepts pouvant résouxre les sous-problèmes
du module portable et de la communcation, qui sont les suivants :
1. Recharger la source d’alimentation électrique du module portable
2. Alimenter en électricité le module portable
3. Traiter les données en provenance du patient
4. Sauvegarder localement les données du patient
5. Afficher localement l’état du module portable
6. Communiquer avec le serveur
Le tableau 5.1 présente les différents aspects à pour y parvenir. Ils se basent sur le cahier
des charges du chapitre 4. Il classe également les critères permettant l’évaluation des solutions
selon l’aspect auquel ils se rapportent.
Dans les sections qui suivent, chacun des sous-problèmes du module portable sera exposé.
Avec chacun de ces sous-problèmes, plusieurs concepts de solutions seront présentés et une
analyse de chacun de ces concepts sera exposée en fonction des aspects à considérer qui se
retrouvent au tableau 5.1.
5.2.1.1
Communiquer avec le serveur
Comme nous l’avons vu au chapitre 4, le système de communication entre le module
portable et le serveur doit respecter certaines conditions en ce qui a trait à sa portée, sa
vitesse de transfert de données, ainsi que la confidentialité et la fiabilité de ce dernier.Plusieurs
concepts de solutions permettent d’implanter un système de communication, dont ceux qui
sont énumérés dans les lignes qui suivent. Cependant, avec les restrictions reliées au projet,
certains vont tout simplement être rejetés.
1. Premier concept - Wi-Fi
Description : Il s’agit d’un groupe de réseau de communication sans fil , par lequel
18
Table 5.1 – Aspects à considérer pour le module portable
Types
Physique
Économique
Temporel
Environnemental
Critères à considérer
Volume
Fiabilité
Poids
Portée du système
Coûts Matériels
Coûts Entretien
Coûts Main-d’oeuvre
Temps de recharge
Autonomie de la pile
Vitesse de transfert
Confidentialité
Contraintes
≤ 2500cm3
≤ 2.5kg
≤ 200000$
≤ 50000$
≤ 200000$
≤ 6heures
≥ 4heures
il est possible de transmettre des données à haut débit, sur de faibles distances. Pour
le système de communication Wi-Fi, c’est la norme IEEE 802.11 qui a été adoptée
sur le plan international. Cette norme regroupe plusieurs révisions qui ont été apportées à la version originale. Parmi ces dernières, on retrouve entre autres les révisions
IEEE 802.11b, ainsi que 802.11i. Normalement, pour ce qui est de la sécurité, certaines
normes exigent l’utilisation d’un réseau privé virtuel (VPN) ou RADIUS. Puisque cellesci ne sont à la base pas suffisamment sécuritaires, il serait hypothétiquement possible à
une tierce personne d’aller chercher les données et pour les modifier. Afin de régler ce
problème, il nous faudra donc soit utiliser le réseau privé virtuel ou RADIUS comme
mentionné ci-dessus, soit utiliser des révisions plus récentes qui ont tenu compte de l’aspect sécurité afin d’optimiser la confidentialité. Par exemple, dans le cas de la norme
IEEE 802.11i, il y a une amélioration au mode de sécurisation WEP (Wired Equivalent
Privacy) implanté par le standart 802.11. Cette révision augmente le processus d’authentification et le chiffrement. À la base, le protocole de sécurisation WEP a éprouvé
certains problèmes. En effet, il a été prouvé que la sécurité de la version initiale a été
facile à violer à l’aide de logiciels tels Aircrack. De nos jours, les versions Wi-Fi ont
tenu compte de ces failles et les données transmises demeurent confidentielles. Généralement, la fiabilité est adéquate chez les réseaux Wi-Fi. Un exemple parfait pour
illustrer cela est la méthode d’accès de la révision IEEE 802.11b. Cette dernière utilise
le CSMA/CA. Contrairement à la méthode d’accès classique utilisée par les machines,
qui est le CSMA/CD, chaque machine ne communique qu’à un moment donné. De
cette manière, les collisions sont évitées. Le procédé de fonctionnement de CSMA/CA
est bien simple. L’émetteur écoute le réseau et si le réseau est engorgé, la transmission
est reportée. Si ce n’est pas le cas, la station émet lorsque le média est libre l’espace
d’un temps donné. Avant l’émission, la station transmet un message RTS (Ready To
Send) qui indique le volume des données à émettre ainsi que sa vitesse de transmis-
19
sion. Le récepteur envoie une réponse CTS (Clear To Send) et c’est à ce moment que
la station débute l’émission des données. Une fois que le récepteur a reçu toutes les
données émises par la station, il envoie un accusé de réception (ACK). Les stations voisines patientent à ce moment-là le temps de la transmission du volume d’information à
émettre à la vitesse donnée. En ce qui a trait à la portée de la communication dans les
réseaux Wi-Fi, elle couvre, en général, un rayon se trouvant entre 20 et 250 mètres. En
ce qui concerne l’aspect financier, le système de communication par Wi-Fi a l’avantage
d’être peu coûteux. En effet, même si l’installation peut sembler onéreuse au départ
(à comparer à un réseau filaire), les coûts d’entretien sont très réduits, ce qui fait qu’à
long terme, l’investissement est facilement rentable. Finalement, pour ce qui est de la
vitesse de transfert, elle se situe entre 1 et 150 Mbps.
Décision : Ce concept est retenu.
Justification : La solution remplit toutes les conditions et les restrictions qui ont été
fixées au chapitre 4.
Références : [2][29][58][59][62][63][64][71][74][75]
2. Deuxième concept - WiMAX
Description : Il s’agit d’un système de communication permettant de transmettre des
données sur une zone géographique étendue (avec un rayon de portée couvrant des kilomètres), à une vitesse de transfert assez élevée (plusieurs dizaines de Mbps). WiMAX
a une seule famille de norme.Il s’agit de la famille IEEE-802.16. Le principe de fonctionnement du système de communication WiMAX est relativement simple. Il s’agit
d’une station de base qui communique avec les antennes des abonnés. Le WiMAX peut
être fixe (fixé sur un toit à la manière d’une antenne de télévision) ou mobile (relier des
clients mobiles à un réseau internet). En ce qui concerne la transmission des données en
soi, il se peut que le concept éprouve certains problèmes. En effet, le WiMAX ne permet
de franchir que de petits obstacles tels des arbres, des maisons, mais non de larges obstacles, tels une colline ou un immeuble. Cela est dû au fait que le WiMAX opère avec
des ondes de fréquences élevées qui pénètrent moins bien les bâtiments et chevauchent
les bandes de fréquences des micro-ondes utilisées par les satellites et les compagnies
de téléphonie cellulaire. Il y a donc un risque de perte de données. Heureusement, ces
contraintes sont rencontrées dans des environnements à haute densité. Dans le cas du
projet Oxypod, vu que l’entreprise baigne dans un environnement de faible densité, la
limitation du spectre ne se fait pas sentir. C’est pour cela que la communication par
WiMAX est fiable. Au niveau de la sécurité de ce concept, il y a quelques risques à
envisager. Puisque le système WiMAX propage les données sur de longues distances,
bien qu’il existe des moyens de protection, il n’est pas impossible que les données soient
assez accessibles comparé à d’autres systèmes de communication. Pour ce qui est des
coûts, étant donné que le réseau Bell à Québec a déjà implanté un réseau WiMAX, les
coûts par rapport à l’utilisation d’un tel système ne sont pas élevés.
Décision : Ce concept est rejeté.
Justification : Puisqu’il n’est pas impossible que les données des clients soient accessibles, la sécurité du système WiMax n’est pas optimale.
20
Références : [2][14][56][31][76][77][78][79]
3. Troisième concept - ZigBee
Description : C’est une technologie qui a pour but le transfert de données à courte
distance (couvrant un rayon d’une dizaine de mètres), à des débits faibles (250 Kbps).
Ce système de communication est basé sur la norme IEEE 802.15.4. Un des avantages
d’un tel concept est son faible coût et le fait qu’il ne consomme que très peu d’énergie
électrique. En ce qui a trait à la sécurité et la confidentialité des données, la norme
802.15.4 n’implante pas un niveau de chiffrement très élevé ainsi qu’une authentification des plus parfaites, mais il y a moyen de l’optimiser. Par exemple, une hausse de
la puissance de la puce engendre une hausse du niveau de chiffrement. À cela s’ajoute
le fait qu’une augmentation de la qualité des composants et du générateur de nombre
aléatoire permet d’améliorer la sécurité. Il ne faut également pas oublier que la qualité
du codage du chiffrement vient également influencer le niveau de sécurité. Si nous tenons compte de tous ces facteurs, il y a certes une solution plausible afin d’optimiser la
confidentialité des données. Finalement, nous pouvons affirmer, pour les mêmes raisons
que la révision IEEE 802.11b du système de communication Wi-Fi, que la technologie
ZigBee est fiable. Cela est dû au fait que cette dernière utilise une méthode d’accès
CSMA/CA. Comme nous l’avons vu ci-dessus, cette méthode envoie un accusé de réception une fois que la transmission des données est complétée.
Décision : Ce concept est retenu sous certaines conditions.
Justification : À la base, le système de communication ZigBee ne remplit pas les restrictions de confidentialité fixées au chapitre 4. Cependant, il y a moyen de l’optimiser,
en tenant compte de certains facteurs.
Références : [2][59][11][80][48]
4. Quatrième concept - Téléphonie cellulaire
Description : C’est un système de communication dans lequel la transmission des
données et de la voix s’effectue par téléphone sans fil. Le fonctionnement de la téléphonie cellulaire est basé sur la radiotéléphonie. Ceci veut dire que les données et la
voix sont transmises par l’intermédiaire d’ondes radioélectriques (Bandes de fréquences
situées entre 900 et 1800 MHz). De nos jours, les systèmes de communications utilisés
ont un fonctionnement en mode numérique. Le principe de ce mode est que les données
sont numérisées et transmises sous forme de bits, qui, une fois reçus, sont synthétisés
de nouveau. Un des avantages d’un tel système est que la qualité de la réception des
données est maximisée. Nous pouvons donc dire que les réseaux de téléphonie cellulaire
de nos jours assurent une transmission fiable et efficace. De plus, la standardisation
des systèmes mobiles a optimisé la compatibilité entre les réseaux. Actuellement, deux
grands standards existent dans le monde occidental. Tout d’abord, il y a la norme
ANSI-41, utilisée en Amérique. Ensuite, il y a le standard GSM, utilisé en Europe. Depuis sa création, la technologie de téléphonie cellulaire a engendré plusieurs générations.
Les générations utilisées de nos jours permettent une vitesse de transfert des données
située entre 384 Kbps (pour la troisième génération) et 100 Mbps (pour la quatrième
génération). En ce qui concerne la sécurité, une technologie de téléphonie cellulaire
21
offre de belles conditions. Il y a un code (NIP) qui protège l’utilisateur d’une fraude
éventuelle de ses données. Chaque appareil a un numéro, le IMEI (International Mobile
Equipement Identity), par lequel le réseau peut l’identifier. Cela dit, en cas de perte
ou de vol, il y a un blocage qui peut se faire au niveau national et international. Ce
blocage ne concerne cependant que son utilisation et non les données qui sont stockées
à l’intérieur. En ce qui a trait à la confidentialité des données en soi, cette dernière est
on ne peut plus sécuritaire. Aucun individu autre que l’opérateur et l’utilisateur n’ont
accès à ceux-ci, à moins, bien sûr, que l’appareil soit perdu. Un autre avantage que
peut avoir ce système de communication est son coût, qui est assez adéquat, puisque
le réseau est déjà implanté à Québec. Pour le projet, on propose le module H24 de
Motorola qui vient avec une carte SIM pour avoir accès au réseau.
Justification : Un tel concept est en mesure de répondre à tous les critères.
Références : [2][81][15][1]
Le tableau 5.3 résume l’analyse de faisabilité des systèmes de communication faite en
fonction des aspects à considérer figurant au tableau 5.1.
Table 5.3 – Analyse de faisabilité du système de communication
Concepts
Wi-Fi
WiMAX
ZigBee
Téléphonie cellulaire
5.2.1.2
Physiques
Oui
Oui
Oui
Oui
Aspects de l’analyse
Économiques Temporels
Oui
Oui
Oui
Oui
Oui
Oui
Oui
Oui
Socio-envir
Oui
Non
Oui mais
Oui
Décision
Oui
Non
Oui mais
Oui
Sauvegarder localement les données du patient
L’ajout d’une mémoire de masse dans le module portable est fondamental, car elle permet
de sauvegarder les informations jusqu’au transfert de données. Selon les besoins du client, les
données doivent être gardées au minimum 7 jours durant. Avec les technologies d’aujourd’hui,
cette dernière spécification n’est plus un problème puisque ce type mémoire possède une
grande capacité de stockage et garde les données après même que le système soit hors tension.
Pour cette partie du module, on priorise un mode de stockage de données qui est facilement
transportable.
1. Premier concept - Module SSD
Description : Un module SSD (Solid State Drive) est constitué de mémoire Flash et
est une alternative nouvellement courante des disques durs. Il existe plusieurs types
de connexion dans ce module allant d’une connexion SATA à une connexion USB.
22
Étant donné que la demande en espace mémoire n’est pas très élevée, le modèle le plus
convivial au projet est le IDE SSD 1.0 de le compagnie Transcend. Ce modèle est souvent
utilisé dans les équipements médicaux. Sa capacité va de 2 Go à 64 Go et l’échange
d’information peu se faire via un interface 35 PIN avec des vitesses d’écriture et de
lecture 10 Mb/sec et 30 Mb/sec. Cela assure une bonne vitesse de transmission avec le
système de communication. Un code correcteur EDC/ECC de 4-bit garantit l’intégrité
des données, donc les risques de perte ou de corruption sont faibles. Un algorithme de
« wear leveling »préserve la mémoire jusqu’à 5 millions de cycles en écriture/effacement.
La demande en énergie est de 0.28 W seulement à 3.3 V et les températures d’utilisation
sont de -40°C à 85°C. La durabilité de ce type de mémoire est très bonne, car le MTBF
de ce système est de 502 ans et la résistance aux impacts est excellente. Le volume
moyen du module mémoire est de 4.6 cm3.Un adaptateur USB est en option afin de
pouvoir connecter directement la mémoire sur un port d’ordinateur. Les modules SSD
sont intéressants, car la gestion de la mémoire est simple et sécuritaire, mais leur prix
semble élevé, soit 30$ pour une capacité de 4 Go.
Justification : Le principe de transport est respecté puisque le module SSD résiste très
bien aux impacts, consomme peu, a un poids et volume faible et les pertes de données
sont pratiquement nulles.
Références : [95][55]
2. Deuxième concept - Carte mémoire
Description : Les propriétés mécaniques des cartes mémoire sont sensiblement le
même que les modules SSD étant donné que les deux sont composées de mémoire Flash.
Les autres propriétés varient cependant selon la qualité et le modèle. Les vitesses de
transfert peuvent varier de 20 Mb/sec à 90 Mb/sec selon le budget alloué. Par exemple,
une carte mémoire de 1 Go peut passer de 10$ à 40$ selon sa rapidité. Certaines cartes
sont plus polyvalentes que d’autres, car elles possèdent deux modes de consommation
d’énergie, soit à 3.3 V ou 5V où la demande en puissance est respectivement 0.3 W à
0.5 W.
La carte mémoire doit absolument être accompagnée d’un lecteur. Malgré tout, c’est
la solution la plus petite, légère et qui procure la plus grande mobilité. Le défaut des
cartes mémoire est qu’on ne peut assurer la qualité et la sauvegarde des données, car
ceci dépend de l’achat et l’utilisation de l’utilisateur. Il existe bien sûr des modes de
recouvrement de données pour certains modèles afin de réduire les pertes de celles-ci.
C’est donc un mode un peu plus risqué que le module SSD.
Justification : La mobilité est optimisée dans ce concept à cause de son faible volume,
de sa résistance aux impacts et de sa possibilité de lecture sur d’autres systèmes.
Référence : [96][23]
3. Troisième concept - Disque dur
Description : À comparer la mémoire Flash qui est fabriquée à partir de composante
électronique, les disques durs sont magnétiques. L’écriture et la lecture de données
23
se font à l’aide d’une tête, qui, grâce au courant, change la propriété magnétique de
la couche extérieure du plateau. Les plateaux sont donc continuellement en rotation
et doivent être contrôlés par un système électrique. Les disques durs sont donc plus
énergivores que la mémoire Flash à cause de la mécanique supplémentaire. De plus,
ils sont davantage imposants. Toutefois, le développement technologique tend de plus
en plus à miniaturiser ce type de mémoire. On retrouve maintenant sur le marché des
disques durs de 1.8 po comme dans les Ipods et de 1 po pour les « microdrives »qui est
le même format que la CompactFlash. Ce dernier a le même fonctionnement qu’une
carte mémoire Flash, mais est un disque dur. Puisque la demande en espace mémoire
est faible et que le transport est priorisé, les « microdrives »sont appropriés pour le
module portable. Ce modèle consomme 0.825 W à 3.3 V et 1.3 W à 5 V. Sa température
d’utilisation est de 0°C à 50°C. Son taux de transfert est cependant assuré à 90 Mb/sec.
Le système se vend aux alentours de 150$. Néanmoins, l’inconvénient des disques durs
est leur fragilité, car ils sont sensibles aux impacts. Pour contrer ce défaut, des systèmes
antichocs ont été ajoutés aux disques durs de format portable.
Justification : Malgré que ce type de mémoire soit répandu, on ne peut garantir
l’intégrité des données, car le système est sensible aux impacts. Les disques durs sont
imposants tant au niveau volume que poids. De plus, les « microdrives »sont du même
format qu’une carte mémoire CompactFlash mais avec des coûts plus élevés, donc les
« microdrives »ne sont pas réellement avantageux, c’est pourquoi on rejette ce concept.
Le tableau 5.5 présente le résumé de l’analyse de faisabilité du stockage des données du
module fait en fonction des aspects présentés au tableau 5.1.
Table 5.5 – Analyse de faisabilité du stockage de données du module
Concepts
Module SSD
Carte Mémoire
Disque dur
5.2.1.3
Physiques
Oui
Oui
Oui
Aspects de l’analyse
Oui
N/A
Oui
N/A
Oui
N/A
Socio-envir
N/A
N/A
N/A
Décision
Oui
Oui
Non
Traiter les données en provenance du patient
Puisqu’il y aura plusieurs données à recevoir et à traiter à partir des signes vitaux du
patient, il a été déterminé que nous aurons besoin d’un microcontrôleur afin de bien gérer
celles-ci. Ils devront être polyvalents pour accepter différents types de périphériques et de
connexions. Les concepts acceptant l’affichage graphique seront priorisés,car c’est une exigence du client. Cette partie du rapport est donc dédiée à l’analyse des concepts efficaces et
le moins coûteux possible permettant le traitement des données.
24
1. Premier concept - PIC18 avec technologie nanowatt (8-bit)
Description : Le microcontrôleur PIC18 (Peripheral Interface Controller) de 8-bit de
la compagnie Microchip est conçu pour des solutions à LCD segmenté, Ethernet et USB
2.0. La technologie nanowatt peut réduire le voltage d’opération jusqu’à 0.35 V ce qui
augmente davantage l’autonomie du module. Une solution simpliste serait d’utiliser un
ensemble incluant déjà les interfaces voulues comme le modèle DM180021. Il inclut 4
Kb de RAM , ainsi que 64 Kb de mémoire Flash, un affichage OLED, un entré mini-B
USB, un lecteur de cartes MicroSD, un clavier « TouchPad »à 5 éléments et des lumières
LED. Des logiciels de programmation en langage C sont inclus avec l’ensemble. Le coût
de l’ensemble revient à 59.98$.
Décision : Le concept est rejeté.
Justification : Malgré que le microcontrôleur PIC 18 soit une solution intéressant
au niveau économique et énergétique, les porfmances de ce type de contrôleur n’est
tout simplement pas assez élevé pour l’Oxypod. De plus, le module DM180021 n’a pas
suffisament de type de connexion possible pour ajouter des modules supplémentaire.
Références :[34][35]
2. Deuxième concept- PIC24 contrôleur d’affichage (16-bit)
Description : Le microcontrôleur PIC24 de la compagnie Microchip est conçu pour
des systèmes d’affichage graphique. Le microcontrôleur PIC24FJ256DA210 possède une
interface pour un affichage direct en monochrome. Le contrôleur accepte les technologies USB, mTouch et plusieurs autres périphériques. Sa mémoire Flash est de 256 Kb,
de même que 96 Kb pour sa mémoire RAM. Il utilise une tension d’opération de 2.2
V à 3.6 V. Il détient 100 PIN dont 84 PIN sont des entrées/sorties digitales. Les périphériques de communication sont nombreux et diversifiés, soit 4-UART, 3-SPI, 3-I2C.
Cette famille de microcontrôleurs est vendue environ 8$ l’unité. Toutefois, le prix sera
augmenté par l’ajout des périphériques.
Décision : Cette solution est retenue.
Justification : Le PIC microcontrôler de 16-bit répond parfaitement à la demande
du client avec une quantité adéquate de mémoire RAM, mémoire flash et une résolution plus que suffisante de 16 bits. L’interface d’affichage direct simplifie grandement
la conception du module. De plus, le nombre de périphérique de communication est
suffisant pour l’ajout de futur périphérique.
3. Troisième concept - IDM (32 bits)
Description : Le module IDM (Intelligent Display Module) de Texas Instruments est
très satisfaisant en terme de performance et de fonctionnalité. Son point fort est son
écran LCD tactile de 3.5" qui améliore l’interaction avec l’utilisateur. Le module inclut
un lecteur de cartes microSD, un haut-parleur, une connexion rs232, 4 convertisseurs
A/N, 16 entrées/sorties digitales et d’autres connexions séries. Sa résolution de 32 bits
est élevée, car c’est beaucoup plus que les besoins nécessaires du module portable.
Son horloge offre une fréquence d’opération de 50Mhz. Il assure pratiquement autant
25
d’ajouts de périphériques que le dernier concept, mais le système embarqué réduit le
temps de main-d’oeuvre nécessaire. Pour ce qui est de la mémoire, il contient environ
la même quantité que le PIC24, soit 256 Kb pour la Flash et 64 Kb pour la RAM. Son
alimentation est faite avec une tension de 5 V à 300 mA. Son volume de 104 cm3 est
tout de même minime compte tenu de toutes les fonctionnalités incluses. Son prix est
de 185$, ce qui en fait la solution la plus coûteuse des trois.
Décision : Cette solution est retenue.
Justification : Le contrôleur IDM offre une grande possibilité de design. Ses performances conviennent amplement pour l’utilisation de l’oxypod et sa consommation
énergétique est très faible.
4. Quatrième concept - ARM avec extension FPGA (32 bits)
Description : Les processeurs ARM sont souvent utilisé pour les systèmes embarqués.
La compagnie Technologic Systems propose des cartes modulaires ayant des processeurs
ARM9 32 bits d’une vitesse de 200 MHz et une mémoire SDRAM de 32 Mb. Certains
systèmes comme le TS-7350 ont des circuit programmable FPGA qui pourrait servir
pour plusieurs applications dont le contrôle d’un écran LCD. Une mémoire tampon de
8 Mb est prévu à cet effet. Le module inclut un port Ethernet, USB 2.0, trois séries, un
lecteur de carte mémoire SD et d’autres types de connexion. L’avantage du module est
que la compagnie offre plusieurs périphérique modulaire qui peuvent se brancher en sur
le module de base. Les types de communications offertes sont nombreuses. Le module
fonctionne sur une tension de 5 à 28 volts à 400 mA. Le prix de base du module est de
129$ et son volume est de 298 cm3.
Décision :Le concept de module ARM est retenue.
Justification : Ce concept est sans nul doute celui le plus performant des quatres.
De plus, il permet de faciliter l’installation de péréphérique par des modules vendus
séparement. Son prix est très compétitif à comparer le processeur IDM, il n’inclut
cependant pas l’écran ACL avec.
Références :[50]
Le tableau 5.7 présente les verdicts de faisabilité du traitement de données pour chacun
des aspects reliés module portable.
Table 5.7 – Analyse de faisabilité du traitement des données
Concepts
PIC18
PIC24
IDM
ARM
Aspects du traitement des données
Physiques Économiques Temporels Socio-envir
Non
Oui
Oui
N/A
Oui
Oui
Oui
N/A
Oui
Oui
Oui
N/A
Oui
Oui
Oui
N/A
Décision
Non
Oui
Oui
Oui
5.2.1.4
26
Afficher localement l’état du module portable
Un écran devra être implanté dans le module afin de permettre à l’utilisateur de vérifier
localement l’état du module. Ainsi, les données affichées comprendront notamment le pourcentage d’oxygène dans le sang et la charge restante dans le module. L’écran pourra aussi
gérer l’affichage d’alarmes visuelles, indiquer si les données sont en train d’être transmises
à la clinique, ainsi qu’afficher d’autres données si cela s’avère nécessaire dans les phases ultérieures du projet. Comme celui-ci est établi directement sur la surface du module, l’écran
devra posséder une taille minimale afin d’éviter de rendre le module trop volumineux. De
plus, l’afficheur sera alimenté par la même source d’énergie portable que le reste du module
de régulation en oxygène.
1. Premier concept - ACL passif
Description :Ce type d’affichage consiste en un écran plat qui utilise les propriétés
optiques de cristaux liquides et de filtres pour polariser et réfracter la lumière. Cette
technologie fonctionne souvent à l’aide d’un rétro-éclairage. La notion d’ACL passif
signifie qu’un pixel de la matrice d’affichage n’est pas alimenté tant qu’il n’est pas
rafraîchi. Cette technologie est en général moins performante que l’ACL actif de par
un contraste plus limité et un taux de rafraichissement plus lent. Toutefois, elle a une
consommation plus faible d’énergie et un coût de production moindre. De plus, le taux
de rafraichissement lent n’est pas une contrainte si l’on n’a pas à afficher de mouvement.
Cette technologie peut être produite en monochromatique, c’est-à-dire avec une seule
couleur, ce qui peut être approprié pour l’affichage de données simples. Certains de
ces écrans peuvent supporter des températures allant de -20◦ C à 70◦ C et une humidité
allant de 0% à 90%. La taille n’est pas un problème puisqu’il existe des modules ACL
à peine plus gros qu’une pièce de monnaie. On peut ainsi facilement obtenir un volume
égal ou inférieur à 30 cm3 . Un module d’affichage tel que le CFAG16032C-YYH-TT de
Crystalfontz America serait un modèle intéressant pour le concept traité.
Justification :Pour nos besoins, un tel écran de type monochromatique serait adéquat.
Cet écran pourrait avoir un volume faible comme 30 cm3 , un poids inférieur à 200 g
et de par les différents modèles proposés, pourrait nécessairement être fonctionnel sur
l’alimentation choisie pour le module. La durée de vie d’un affichage ACL peut être de
plus de 30 000 heures, c’est-à-dire plus de 3 années à être allumé, sans interruption.
Finalement, le coût pour ce type d’affichage peut être sous les 50$ l’unité, ce qui est
très peu dispendieux.
Références :[18][85][86][16]
2. Deuxième concept - Plasma
Description :Cette technologie repose sur de petites cellules de plasma qui sont des
chambres de gaz illuminées par de l’électricité à la manière de néons. La lumière ultraviolette produite par ces cellules remplies d’argon et de xénon est ensuite utilisée
pour allumer les pixels de l’écran formés d’une section bleu, verte et rouge. Cela permet de produire plus de 2563 couleurs pour former une image. Ces écrans possèdent un
haut contraste et peu de distorsion. Par contre, bien que cela tende à être de mieux en
27
mieux, les écrans plasmas ont historiquement eu plusieurs problèmes d’images restant
brulées sur l’écran s’il n’y a pas assez de mouvement. Le panneau de verre peut aussi
rendre le poids de l’écran plus important que celui d’un ACL qui utilise un panneau de
plastique. La consommation énergétique est importante et les coûts sont relativement
élevés puisque le plasma est produit en quantité inférieure à ses compétiteurs. Ainsi,
le coût d’un tel affichage dépasse les 100$ alors que les plus petits poids et volumes
disponibles pour des modules plasmas sont de plus de 400g et plus de 300 cm3 respectivement. Un tel écran peut fonctionner de 0◦ C à 70◦ C avec une humidité allant de 0 à
90%. La durée de vie d’un écran plasma peut aller jusqu’à 60 000 heures, soit presque
7 ans allumé. L’angle de vision proposé est de 75◦ de chaque côté de la normale.
Justification :Bien que ce type d’affichage réponde à la plupart des critères de base
établis plus haut, il présente quelques problèmes éventuels. Comme les données affichées ne sont pas des images et ne fluctueront pas beaucoup, il est possible qu’à force
de rester allumé, les données restent brulées sur l’écran. L’écran n’est pas censé être
utilisé sous 0◦ C, alors qu’au Québec, il est fortement probable qu’il soit exposé à des
températures encore plus faibles. La consommation électrique, le coût et le poids sont
plus élevé que ses compétiteurs, en plus des problèmes décrits plus haut contrecarrent
les avantages que pourrait avoir la technologie dans une autre situation.
3. Troisième concept - OLED
Description :OLED signifie Örganic light-emitting diode ,̈ c’est donc une diode composée de couches organiques semi-conductrices placées entre deux électrodes. Cette
technologie peut être utilisée autant pour des téléviseurs que pour des ordinateurs, des
cellulaires ou modules portables quelconques. La technologie OLED n’utilise pas de
rétro-éclairage ce qui permet d’obtenir de meilleurs contrastes de couleurs. Le coût actuel est un peu plus important que celui de l’ACL, mais promet, d’ici quelques années,
de devenir inférieur de par la production de masse. Cette sorte d’écran est durable,
flexible de par sa faible épaisseur. Cet écran offre aussi un angle de vision important,
près de 90◦ par rapport à la normale, et ce, en raison du fait que chaque pixel émet
de la lumière. Le coût en énergie de l’OLED est réduit par rapport à l’ACL puisque
tout pixel éteint ne consomme pas d’énergie, alors que pour l’ACL, le rétro-éclairage
est toujours allumé et consomme de l’énergie. Le temps de rafraichissement est plus
rapide que de l’ACL. Par contre, la durée de vie est réduite puisqu’elle peut n’être que
de 14 000 heures, soit environ 1 an et demi à être allumé. Un écran OLED peut résister
à une température de -20◦ C à 70◦ C et une humidité de 0 à 90%. Ce type d’écran peut
être très petit. Bien que plus récent comme technologie, l’OLED présente certains avantages intéressants qui font qu’il mérite d’être considéré. Un module d’affichage tel que
le CFAL12864Z-G-B2 de Crystalfontz America serait un bon choix pour ce concept.
Justification :Ce type d’affichage serait aussi convenable pour notre utilisation. Il
serait pertinent de prendre un OLED passif monochromatique puisque l’on ne néces-
28
site pas vraiment un vaste contraste ou une rapidité de rafraichissement phénoménale.
Pour moins de 100$, il serait ainsi possible d’avoir un écran convenable avec un poids de
moins de 30g et un volume de moins de 30cm3. Comme mentionné plus haut, la durée
de vie est de 14 000 heures à être allumé, mais cela représente davantage le temps pour
lequel l’écran a la meilleure luminosité, et non le temps avec un bris. De plus, si nécessaire, un système de mise en veille de l’écran avec un bouton pourrait être implanté
pour augmenter le nombre d’années où le système est parfaitement fonctionnel.
Références :[19][88][17]
Le tableau 5.9 résume l’analyse de faisabilité concernant l’affichage des paramètres du
module, qui est établi en fonction des aspects qui se retrouvent au tableau 5.1.
Table 5.9 – Analyse de faisabilité de l’affichage des paramètres
Concepts
ACL
Plasma
OLED
5.2.1.5
Aspects de l’affichage des paramètres
Oui
Oui
Oui
N/A
Non
Oui
Oui
N/A
Oui
Oui
Oui
N/A
Décision
Oui
Non
Oui
Alimenter en électricité le module portable
Avec comme objectif de bien répondre aux besoins du client, il serait malvenu d’omettre
l’alimentation électrique du module portable. Le concept d’alimentation doit tenir compte de
l’utilisation quotidienne du module portable, donc la source de tension doit être rechargeable.
Le système de contrôle du débit massique est très énergivore et demande une tension continue
de 12 V. Le type d’alimentation choisi devra donc fournir cette tension et posséder une
capacité suffisante pour subvenir au besoin du module pendant 4 heures. Pour l’instant, on
fixe le courant utilisé à 600 mA afin d’évaluer la durée de la pile. La prochaine section est
dédiée aux différents types de batteries rechargeables disponibles sur le marché avec leurs
principaux avantages et inconvénients.
1. Premier concept - Batteries lithium-ion
Description :Ce type d’arrangement permet d’obtenir un voltage supérieur à la majorité des batteries normalement disponibles sur le marché (soit 3.6-3.7 V, par rapport
aux 1.5 V usuels). L’énergie spécifique d’un tel type de batterie est entre 100 et 250
W h/kg. Sa durée utile en termes de cycles est de 400 à 1 200 cycles. Le montage suggéré est composé de 4 batteries lithium-ion de la compagnie Propel. Le modèle fourni
une tension de 14.8 V à 2600 mAh se qui est suffisant pour durer minimum 4 heures.
Le poids et la dimension de la batterie sont respectivement 170 g et 95 cm3. Son prix
actuel est de 55$.
Décision : Le concept est retenu.
29
Justification : : Puisque le module portable devra disposer d’une vitesse de recharge
relativement rapide, il est actuellement reconnu qu’une batterie au lithium-ion soit une
des plus efficaces en ce domaine. De plus, elle assure une autonomie suffisante.
2. Deuxième concept - Batterie alcaline
Description :Cette solution conviviale permet l’utilisation de formats standards de
batteries tels les traditionnels AAA, AA et les « snap-on »de 9 V. De plus, en tant normal, une telle batterie a une efficacité charge/recharge de 99.9%. Le principal avantage
de ce type de batterie est qu’elle réduit les effets indésirables sur l’environnement. Cependant, la technologie des piles alcalines rechargeables n’est pas encore au point, car
le nombre de cycles est limité à seulement 60 recharges et le temps de recharge varie de
12 à 16 heures. Notre solution proposée serait donc 8 batteries alcalines rechargeables
de type AA de 1.5V à 2000 mAh provenant de la compagnie Envirocell. L’ensemble
revient à 16$ le paquet de 8 piles.
Justification : Étant donné que le temps de recharge dépasse celui qui était fixé dans
les contraintes, on n’a pas d’autres choix que de rejeter ce concept. De plus, la durée
de vie est trop courte et ce type de pile est difficilement trouvable sur le marché.
3. Troisième concept - Batterie nickel-hydrure métallique
Description : Les piles Ni-MH rechargeables sont les plus répandues sur le marché.
La tension de batterie domestique d’usage est de 1.2 V. Son grand avantage est sa
rapidité de charge qui est moins d’une heure et elle fournit une tension pratiquement
continue pendant sa décharge. Le modèle qui est suggéré pour le module portable est
une batterie de 12 V de 4500 mAh. Le poids et le volume sont très élevés, soit 454 g et
254 cm3. À défaut d’un certain confort, cette pile procura une autonomie de plusieurs
heures.
Justification : Son autonomie est le principal avantage de cette pile. Elle devra toutefois être jumelée avec des concepts qui possèdent des volumes et poids faibles.
Dans le tableau 5.11, nous retrouvons le résumé de l’analyse de faisabilité de l’alimentation
du module faite en fonction des aspects énumérés au tableau 5.1.
5.2.1.6
Recharger la source d’alimentation électrique du module portable
Cette section propose des concepts pour la recharge avec la prise électrique. D’une manière
générale, le temps de recharge idéal est donné par : Temps de recharge idéal = Capacité de
la batterie / Courant de charge. Le courant charge C est le courant qui décharge ou charge la
batterie en une heure. Le temps de recharge réel est égal : Temps de recharge réel = Temps de
recharge idéal/Efficacité. Pour la batterie Li-Ion, la méthode de recharge est celle du courant
continu - tension continue (citation). Pour la batterie Ni-MH, il est possible de recharger la
30
Table 5.11 – Analyse de faisabilité de l’alimentation du module
Concepts
Lithium-ion
Alcaline rechargeable
Nickel-zinc rechargeable
Oui
Oui
Oui
N/A
Oui
Oui
Non
N/A
Oui
Oui
Oui
N/A
Décision
Oui
Non
Oui
batterie par la méthode de recharge rapide (avec pour conditions d’arrêt ∆V ou ∆T ).
1. Premier concept - Recharge embarquée
Dans ce concept, le chargeur est intégré au module portable. Cela permet de simplifier
l’utilisation pour le patient. Pour le charger la batterie, il doit seulement brancher le
port de recharge au réseau électrique domestique. L’avantage de ce concept est qu’il
permet à l’utilisateur de recharger la batterie peut importe l’endroit où il se trouve,
ce qui augmente son autonomie de déplacement. Cependant, il immobilise le patient
durant la recharge. De plus, le poids et le volume du module portable augmentent,
quoique ces valeurs occupent une portion raisonnable du total, soit 6% de chacun (140
g et 150 cm3 pour les chargeurs Li-Ion et Ni-MH. Ils coûtent généralement près de
100$). Décision : Ce concept est retenu.
Justification :Même s’il restreint la liberté d’action du patient lors de la recharge, le
poids, le volume et le coût en matériaux de ce concept respecte les barèmes.
Références :[46][47][9][10]
2. Deuxième concept - Recharge sur socle externe
Dans ce concept, la recharge d’une batterie s’effectue en la retirant du module portable et en la plaçant sur un socle externe. Elle est remplacée par une autre à pleine
capacité. Le principal avantage de ce concept est que la mobilité du patient n’est plus
contrainte lors de la recharge. Cependant, son autonomie de déplacement est limitée
par l’autonomie de la pile. Comme aucune partie n’est ajoutée au module portable, le
poids et le volume n’augmentent pas et remplissent donc adéquatement les barèmes.
Par contre, le coût matériel du système augmente, car il nécessite obligatoirement une
batterie supplémentaire.
Justification :Malgré une liberté d’action moindre en raison de l’absence de chargeur
intégré, ce concept répond entièrement aux critères de poids, de volume et de coûts des
matériaux.
Références :[46][47][9][10]
3. Troisième concept - Recharge mixte
Cette solution est un mélange des deux concepts précédents. Un chargeur est intégré
au module portable et un socle de recharge externe est prévu. Cela permet au patient
de recharger sa batterie peut importe l’endroit où il se trouve. De même, il peut éviter
31
d’être immobilisé en remplaçant sa pile à plat par une pleinement chargée par le socle
externe. Le désavantage de ce concept est le poids et le volume augmenté du module
et les coûts matériels qui augmentent, car il faut prévoir deux chargeurs (près de 200$)
et deux batteries).
Justification :Ce concept est le plus versatile. Il offre le plus de possibilités de recharge
au patient et ne restreint pas ses déplacements. Cependant son poids, son volume et
son coût matériel sont les plus élevés.
Références :[46][47][9][10]
Table 5.13 – Analyse de faisabilité de la recharge de la source d’énergie
du modle portable
Concepts
Recharge intégrée
Recharge sur socle externe
Recharge mixte
5.2.2
Physiques
Oui
Oui
Oui
Aspects de la recharge
Oui
Oui
Oui
Oui
Oui
Oui
Socio-envir
N/A
N/A
N/A
Décision
Oui
Oui
Oui
Serveur et base de données
Le serveur servira de lien entre le module du patient et l’interface du médecin. C’est lui
qui aura la charge de recueillir les données stockées dans le module, de les enregistrer et de
les transmettre au médecin. À partir de la figure 5.1, nous pouvons analyser que le serveur
est relié à 2 sous-problèmes qui sont :
1. Gérer et transférer les données de l’ensemble des patients
2. Sauvegarder les données dans une base de données
Le tableau 5.15 représente les différents aspects à considérer, basés sur le cahier des charges
du chapitre 4, pour le serveur. Ce tableau résume également les différents sous-problèmes
reliés à ce dernier. Dans les sections qui suivent, chacun des sous-problèmes du serveur seront
exposés. Avec chacun de ces sous-problèmes, plusieurs concepts de solutions seront présentés
et une analyse de chacun de ces concepts sera exposée en fonction des aspects à considérer
qui se retrouvent au tableau 5.15.
5.2.2.1
Sauvegarder les données dans une base de données
Dans le projet, certaines demandes du client impliquent que les données devront être
disponibles presque en tout temps afin d’être consultées ou mises à jour. Ceci implique l’utilisation de serveurs où les données seront entreposées.
32
Table 5.15 – Aspects à considérer pour le serveur
Types
Physique
Économique
Temporel
Environnemental
Fiabilité
Coûts Matériels
Coûts Entretien
N/A
Confidentialité
Contraintes
≤ 200000$
≤ 50000$
1. Premier concept - Location d’un serveur distant
Description :La location d’un serveur dédié a l’avantage de posséder des coûts très
prévisibles. Dans les services offerts par Netissime, on offre un serveur possédant un
intel Xeon dual core de 3GHz, 500 Go de stockage, 4Go de mémoire vive et des disques
en raid 1. Une connectivité de 100Mbps et une disponibilité de 99,9% sont garanties. Le
système de gestion de base de données MySQL est inclus. Le coût est de 2747,88€ pour
une année. Cela équivaut à environ 3900$ si le taux de change est de 1,42$ pour 1€.
Un autre avantage est de ne pas avoir à se préoccuper de l’entretien physique et d’être
sûr de ne pas avoir à engager du personnel pour l’entretien des installations ou pour le
maintien de cette partie du projet. Il suffit de renouveler le contrat chaque année.
Justification :Cette solution satisfait nos critères de stabilité et de performance. Les
coûts sont prévisibles et semblent raisonnables. Cependant, ils peuvent rapidement
exploser avec l’ajout de nouveaux services au contrat de location.
Références :[41]
2. Deuxième concept - Achat d’un serveur
Description : Il y a aussi la possibilité d’acheter un serveur qui sera localisé à l’emplacement de la clinique. Cette solution optimise la vitesse et la sécurité de transmission des données sur le réseau local. Un exemple de serveur serait le : « CybertronPC
XVA9080 Imperium Tower Server ». Cet ordinateur possède deux processeurs « Xeon
Quad Core »cadencés à 2.00GHz, 6Go de mémoire vive « ECC 1 »extensible à 24Go, 4
disques durs de 500 Go préconfigurés en raid 5 retirable à chaud et une garantie de 3
ans. Le tout pour 2432$. Il peut aussi être nécessaire d’utiliser un onduleur qui s’occupe de protéger le serveur en cas de surtension et de l’alimenter en cas de pannes de
courant ou sous-tension. De plus, un onduleur permettra au serveur de se fermer correctement si la panne s’éternise. La durée d’autonomie d’un onduleur est déterminée en
VA (volts*ampères). Notre serveur possède une alimentation maximale de 460 watts.
Cependant, il s’agit d’une valeur absolue et le serveur ne devrait jamais consommer
cette puissance. L’onduleur « APC Smart-UPS 2200VA LCD 120V »devrait faire l’affaire puisque le manufacturier assure que son produit peut soutenir 460 watts pendant
1. Error Correction Coding ou, autrement dit, une mémoire auto-correctrice
33
56,4 minutes. Il en coûte 890$ et la durée de vie des batteries est de 3 à 5 ans. Une
nouvelle batterie coûte 346$.
Décision :Ce concept est retenu.
Justification :Cette solution satisfait nos critères de stabilité et est performante. Les
coûts semblent raisonnables et ne risquent pas trop de grimper même si l’on voulait
améliorer l’implantation (exemple : ajout de mémoire vive). De plus, ce système nous
permet de demeurer en contrôle du service offert au client et ainsi que de l’évolution
de celui-ci.
Références : [20][53][13][6][12]
3. Troisième concept - Amazon Relational Database Service
Description : Amazon Relational Database Service est l’un des nombreux services
offerts par Amazon dans sa gamme de services internet. En résumé, c’est un outil qui
nous permet d’avoir sa base de données de type MySQL dans un nuage informatique.
La tarification est directement proportionnelle à l’utilisation. Cela en fait un service
très avantageux économiquement, car il en coûtera très certainement moins de 100$
par mois. De plus, si le service ne nous donne pas entière satisfaction durant la phase
1 de test, il est très facile de changer d’option pour une autre parce qu’aucune durée
de contrat n’est déterminée. L’accès aux données est garanti à plus de 99,95% et des
services de sauvegarde sont offerts à prix dérisoires.
Décision : Ce concept est accepté.
Justification : Cette solution satisfait nos critères de stabilité et de performance. Les
coûts sont prévisibles et semblent très raisonnables. De plus, cette solution nous laisse
toute la liberté de mouvement si jamais des modifications doivent se faire ou s’il faut
envisager une autre solution.
Au tableau 5.17 résume l’analyse de faisabilité pour le stockage de données du serveur,
qui est faite en fonction des aspects qui se trouvent au tableau 5.15.
Table 5.17 – Analyse de faisabilité du stockage de données du serveur
Concepts
Location de serveur dédié
Achat de serveur
Amazon RDS
5.2.2.2
Oui
Oui
N/A
N/A
Oui
Oui
N/A
N/A
Oui
Oui
N/A
N/A
Décision
Oui
Oui
Oui
Gérer et transférer les données de l’ensemble des patients
Le système de gestion de base de données est un ensemble de logiciels utilisés afin de gérer,
consulter et construire une base de données. Dans notre cas, l’avantage d’un tel système par
34
rapport au stockage sous forme de fichiers tels que les fichiers textes ou les fichiers XML 2
est que les bases de données permettent de gérer les accès en écriture/lecture simultanées
et permet de limiter les droits d’accès selon les utilisateurs. Les SGBD 3 sont aussi reconnus
pour offrir un meilleur niveau de performance, de sécurité et de simplicité.
1. Premier concept - PostgreSQL
Description :PostgreSQL est un système de base de données relationnelle et objet.
Son utilisation est régie par la licence BSD 4 et permet son utilisation gratuitement
dans des projets commerciaux et libres. Il est supporté par une communauté mondiale
de développeurs. Il est reconnu pour ses performances et il est portable sur presque
tous les systèmes d’exploitation Unix tels que Mac OS X et les systèmes d’exploitation
Windows.
Justification :Ce logiciel répond à nos besoins. Il entrepose nos données de façon
sécuritaire, fiable et efficace tout en étant gratuit et flexible, car il pourra fonctionner
sur presque n’importe quels systèmes d’exploitation.
Références : [44][69][70][25][98]
2. Deuxième concept - Oracle
Description : Oracle est aussi un SGBDRO 5 . Il est de type propriétaire. Cela veut
dire qu’il est nécessaire de payer pour son utilisation. La licence la plus basique coûte 1
293$ pour la phase 1du projet (1 an et 1 processeur) et 6 464$ pour la licence perpétuelle
(1 processeur). Les prix pour la version entreprise sont respectivement 10 587$ et 52
934$. Il est portable sur les principaux systèmes d’exploitation utilisés actuellement.
Son utilisation type est sur un serveur où il peut gérer d’importantes bases de données.
Justification : : Ce logiciel répond à nos besoins. Il entrepose nos données de façon
fiable, sécuritaire et efficace. Il pourra fonctionner sur la grande majorité des systèmes
d’exploitation. Il a le désavantage d’être très onéreux.
Références : [45][8][67][68]
3. Troisième concept - SQLite
Description :SQLite est un système de base de données relationnelle. La particularité
de SQLite est son poids qui est d’environ 200 à 600 Ko. Cela permettrait son utilisation
dans un système embarqué comme le module portable. Les données y seraient enregistrées sous forme de base de données au lieu de fichiers textes ou XML 6 . Le problème
d’une base de données du genre est qu’elle n’est pas optimisée pour une utilisation
du type client-serveur. En effet, cette application n’est pas performante pour les accès
simultanés en écriture et lecture. Un point positif est que son code source est du domaine public et permet son utilisation de manière propriétaire et « open source »tout
2.
3.
4.
5.
6.
Extensible Markup Language
Système de gestion de base de données
Berkeley software distribution license
Système de gestion de base de données relationnelle et objet
35
à fait gratuitement. Il est portable à toutes les architectures informatiques ayant un
compilateur C respectant la norme ANSI 7 .
Justification :Ce système ne serait pas performant une fois les données rendues au
serveur parce qu’il serait impossible d’écrire une donnée pendant la lecture d’une autre.
Bref, il gère très mal le multi-utilisateur et ne permet pas de restreindre les droits d’accès selon l’utilisateur.
Références : [54][73][49][22][61]
4. Quatrième concept - MySQL
Description :MySQL est un SGBDR 8 assez performant et répandu. À l’origine, celuici était entièrement libre, mais depuis le rachat de Sun Microsystems par Oracle Corporation, il est maintenant disponible sous deux licences. L’une est libre pour les projets
libres et l’autre est propriétaire pour les projets de nature commerciale. Il coûte 2232$
par année pour l’installer sur un serveur et il n’y a pas réellement d’aubaines, même si
l’on signe pour plusieurs années. Il est multi-utilisateur et ses performances sont optimisées pour la lecture des données. Il est déjà implémenté dans de nombreux langages
de programmation et est portable sur de nombreux systèmes d’exploitation.
Justification :Les besoins que nous avons seront satisfaits avec cette solution. Il entrepose et gère nos données de façon fiable, sécuritaire et efficace. Son implantation est
facilitée à cause de nombreux langages qui l’incorporent pour une utilisation transparente. Il est portable sur de nombreux systèmes d’exploitation, mais la version commerciale est très onéreuse.
Références :[45][40][65][66]
La faisabilité du transfert et de la gestion des données du serveur, qui sont faite en fonction
des aspects énumérés au tableau 5.15 sont résumées au tableau 5.19.
Table 5.19 – Analyse de faisabilité du transfert et de la gestion des données du serveur
Concepts
PostgreSQL
Oracle
SQLite
MySQL
Oui
Oui
N/A
N/A
Oui
Oui
N/A
N/A
Non
Oui
N/A
N/A
Oui
Oui
N/A
N/A
7. American National Standards Institute - ANSI
8. Système de gestion de base de données relationnelle
Décision
Oui
Oui
Non
Oui
5.2.3
36
Interface
L’interface est l’outil dont se sert les médecins pour effectuer le suivi médical à distance
des patients. Une interface doit pouvoir le supporter en lui permettant de pouvoir avoir accès
données médicales des patients, de les schématiser pour les faciliter leur interprétation,etc.
Elle doit également permettre la configuration des modules d’une manière simple et efficace.
L’interface a donc un impact majeur sur l’utilisation du système paf les médecins. À partir de
l’analyse du diagramme fonctionnel 5.1, deux sous-problèmes ont été identifiés par rapport à
l’interface :
1. Présenter l’information, permettre l’intervention à distance et la configuration des modules
2. Choisir un langage de programmation pour l’interface
Les aspects à considérer pour ces sous-problèmes sont présentés dans le tableau 5.21
Table 5.21 – Aspects à considérer pour l’interface
Types
Physique
Économique
Temporel
Environnemental
5.2.3.1
Compatibilité
Complexité de développement
Facilité d’utilisation
Coûts Entretien
Coûts Main-d’oeuvre
N/A
N/A
Contraintes
≤ 50000$
≤ 200000$
Présenter l’information, permettre l’intervention à distance et la configuration des modules
1. Premier concept - Interface graphique locale (GUI)
Description : Une interface graphique offre un environnement visuel qui permet à
l’utilisateur d’interagir avec la machine. L’environnement graphique est composé principalement de fenêtre, de menus, des éléments de contrôle (boutons, liste défilante, etc.)
d’icônes et d’un pointeur, qui est généralement contrôlé par une souris. Les actions que
souhaite accomplir l’usager sont effectuées par la manipulation des éléments graphiques.
Concrètement, ce concept correspond à un programme installé localement sur les ordinateurs des médecins. L’avantage de cette méthode est la facilité avec laquelle les
actions peuvent être accomplies. Ce concept satisfait déjà quelques points du critère de
facilité d’utilisation (présence de raccourcis, dialogue simple et naturel) et il rencontre
donc minimalement celui-ci.
Description : Ce concept est retenu.
Justification :Les médecins ne disposent pas nécessairement de connaissances poussées en informatique. La simplicité de l’utilisation des interfaces graphiques leur permet
37
quand même d’effectuer leurs tâches sans demander de formations supplémentaires importantes. De plus, ce concept supporte bien la schématisation des données des patients
sous forme de graphique. Références :[90][92][91]
2. Deuxième concept - Interface Web (WUI)
Description : Une interface Web est une sous-classe des interfaces graphiques. Elle
accepte des entrées et produit des sorties qui sont transmises à l’utilisateur via le réseau Internet sous la forme de page web. L’usager accède à ce type d’interface par un
fureteur web. L’avantage de cette méthode est qu’il n’est pas nécessaire d’installer un
programme localement. Cependant, une connection Internet est obligatoirement requise
pour le médecin. Les critères du cahiers des charges sont également minimalement satisfaits, puisqu’il s’agit d’une sous-classe des GUI (voir concept 1).
Description : Ce concept est retenu.
Justification :Cette méthode n’impose pas l’installation de logiciel, ce qui permet
d’éviter des problèmes de compatibilité matériel. De plus, les cliniques médicales possèdent pratiquement toutes un accès Internet. En outre, un médecin peut y accéder
ailleurs qu’à son bureau.
3. Deuxième concept - Interface par ligne de commande (CLI)
Description : Dans ce type d’interface, les interactions entre l’usager et la machine
s’effectue en mode texte. L’utilisateur entre des commandes sous la forme de texte.
L’interpréteur de commande les analyse et produit les actions désirées. Le désavantage
de ce concept est sa difficulté d’approche et la courbe d’apprentissage qui est tès prononcée ; en effet l’utilisateur doit avoir une connaissance importante des commandes
et des options pour l’utiliser. Ce concept répond minimalement à certains points du
critère de convivialité (au niveau de la gestion des erreurs).
Description : Ce concept est rejeté.
Justification :Les médecins ne possèdent généralement pas les connsaissances nécessaires pour utiliser ce type d’interface. De plus, effectuer des tâches complexes peut être
long et fastidieux, voire frustrant. De même, ce concept intègre mal la schématisation
des données sous forme graphique. Ce concept n’est donc pas approprié pour la clientèle
visée et à ses besoins.
5.2.3.2
Choisir un langage de programmation
Il faut choisir le langage de programmation qui convient le plus à la programmation des
interfaces. Selon nos critères, il faudra que le langage soit qu’il soit portable, c’est-à-dire qu’il
soit compatible avec plusieurs différents types d’OS. Il faut aussi que les langages ne soit pas
trop complexe, car cela permet de réduire les coûts de maintenance et de production du code.
38
Table 5.22 – Analyse de faisabilité - Présenter l’information, permettre
l’intervention à distance et la configuration des modules
Concepts
GUI
WUI
CLI
Oui
Oui
N/A
N/A
Oui
Oui
N/A
N/A
Non
Oui
N/A
N/A
Décision
Oui
Oui
Non
1. Premier concept - JAVA
Description :Le JAVA est un langage de programmation orienté objet. Il est très facile
de programmer en JAVA. Les concepteurs du langage ont décidé de ne pas ajouter
des éléments compliqués provenant d’autres langages (comme la notion de pointeurs).
Comme le JAVA est interprété, il est compatible avec toutes les plates-formes (Windows,
Linux, Mac, etc. . .). De plus, il est facile au programmeur de comprendre et de se
retrouver dans son code. Le JAVA n’est pas un langage qui requiert beaucoup de lignes
de codes et les programmes ne nécessite pas beaucoup d’espace mémoire. De plus, la
taille réduite du code facilite la maintenance du code.
Décision :Ce concept est retenu.
Justification :Le JAVA semble être le langage approprié pour coder notre interface,
car il répond bien à tous nos critères. Il est simple,facile à utiliser et fonctionne sur tous
les OS. Il est sécuritaire, très peu volumineux et sa maintenance est peu coûteuse. De
plus, il est très performant.
2. Deuxième concept - C++
Description : Le C++ est un langage très populaire en programmation. Il est réputé
pour son efficacité et sa rapidité d’exécution. Cependant, programmer en C++ s’avère
être difficile, puisque c’est un langage complexe (Pointeur, Classes,etc.). Le C++ a besoin d’un compilateur pour que le code soit exécutable. Cela lui permet d’être portable
à un certain niveau, car le concepteur n’a qu’à utiliser un compilateur propre à chaque
OS. Au point de vue budgétaire, le C++ s’avère être un langage très fiable, performant
et une maintenance peu coûteuse. Par contre, le code peut être très long, donc onéreux
parce que c’est long à développer. Sa maintenance sera longue, mais ne se fera pas aussi
souvent que les autres langages vus sa performance. Il ne satisfait donc pas le critère
de complexité de développement.
Justification : Même si le C++ est un langage très performant et n’a pas besoin d’une
grande fréquence de maintenance, il reste qu’il s’agit d’un langage complexe et de très
grande taille, ce qui ne convient pas à nos critères.
Références :[21]
39
3. Troisième concept - Python
Description :Le Python est un autre langage de type orienté objet. Il s’agit d’un autre
langage peu répandu, mais qui prend de l’expansion. Le but premier du Python est sa
facilité d’utilisation, car le code se lit comme un texte. De plus, les fonctions sont claires
et précises. Un programme en Python est portable, ce qui signifie qu’il peut opérer sur
tous les OS grâce à son compilateur intégré. Programmer en Python donne un code
très court comparé au C++, donc il n’est pas difficile au programmeur de se retrouver
dans son code, car tout est lisible. De plus, étant donné que le code est court, son coût
de production est moindre et sa facilité de maintenance se voit augmentée.Cependant,
sa rapidité d’exécution laisse un peu à désirer.
Décision : Ce concept est retenu sous certaines conditions.
Justification : Comme le JAVA, le langage Python est très facile à utiliser, portable
et peu complexe. Le code est court, mais sa vitesse d’exécution est plutôt faible. Cependant, il existe un moyen d’optimiser sa vitesse à l’aide du module Cython. Puisque
Cython permet d’utiliser des fonctions écrites en C, ainsi le code gagne en rapidité
d’exécution. Avec Cython, le langage Python semble être adéquat pour créer notre interface.
Le résumé de l’analyse de faisabilité du choix du langage de programmation se retrouve
dans le tableau 5.24.
Table 5.24 – Analyse de faisabilité du langage de programmation de l’interface
Concepts
Java
C++
Python
Oui
Oui
N/A
N/A
Non
Oui
N/A
N/A
Oui mais
Oui
N/A
N/A
Décision
Oui
Non
Oui mais
Chapitre 6
Étude préliminaire
Pour faire suite à l’analyse de faisabilité qui nous a permis d’énumérer différentes solutions répondant aux divers sous-problèmes et d’en retenir les plus intéressants, l’étude
préliminaire présentera l’élaboration de concepts globaux formés des sous-solutions trouvées
préalablement. Ces concepts seront alors décrits, analysés et comparés afin de pouvoir déterminer lequel est le meilleur pour les besoins du client et sera donc ultimement retenu.
6.1
Concepts retenus et plans de développement
6.2
Concept 1
6.2.1
Description
En tant que premier concept global, il a été décidé que celui-ci aurait comme objectif principal la simplicité d’utilisation pour le patient de même qu’un coût minimal. Les principales
composantes de ce concept seront, entre autres, le serveur central Amazon, le microcontrôleur PIC24 de Microchip, de même qu’un affichage ACL. Comme alimentation, il a été décidé
qu’une pile lithium-ion polymère serait idéale, avec une recharge intégrée de celle-ci. De plus,
le type de communication qui a été retenu pour ce concept consiste en un réseau de téléphonie
cellulaire.
6.2.2
Module : concept 1
Fiabilité : La valeur du MTBF est le moyen le plus simple pour évaluer la fiabilité du
système. Pour le module portable, on choisira le plus petit MTBF car c’est la pièce qui va
se briser en premier. Le PIC 24 de la compagnie Microchip permet un bonne flexibilité et
s’adapte bien à la réalisation du projet. En ce qui concerne son MTBF, puisqu’il est impossible dans un temps limité d’effectuer des tests visant à calculer sa fiabilité et que sa
fiche technique ne dit rien à ce sujet, on doit se contenter d’une comparaison avec des systèmes déjà existants. Le MTBF de microprocesseur de même type est donc d’environ 219
40
41
CHAPITRE 6. ÉTUDE PRÉLIMINAIRE
Table 6.1 – Plan d’étude pour le module portable
Critères
4.1.1Fiabilité
Procédures et hypothèses
Considérer la pièce la moins fiable selon
le barème.
4.1.2Autonomie électrique
Calculer selon la consommation de chacune des pièces. Les puissances sont
prises à partir des valeurs typiques de
tension et d’ampérage.
Estimer à partir de la pile considérée.
Additionner le volume de chaque composante.On considère seulement les
composantes principales du design. Le
volume est déterminé à partir des grandeurs hors-tout
Additionner le poids de chaque composante.Les composantes secondaires ne
sont pas incluses
4.1.3Temps de recharge
4.1.4Volume
4.1.5Poids
Références
[16] [17] [18] [23]
[28] [55] [34] [35]
[37] [52] [46] [47]
[16] [17] [18] [23]
[28] [55] [34] [35]
[37] [52]
[46]
[16]
[28]
[37]
[47]
[47][42][43]
[17] [18] [23]
[55] [34] [35]
[52] [46] [47]
[42] [43]
[16]
[28]
[37]
[47]
[17]
[55]
[52]
[42]
[18] [23]
[34] [35]
[46] [47]
[43]
Table 6.3 – Plan d’étude pour la communication
Critères
4.2.1Portée
4.2.2Vitesse de transfert
4.2.3Fiabilité
4.2.4Confidentialité
Estimer la portée selon la technologie.
Estimer la vitesse de transfert selon la
technologie. On considère les vitesses
minimum des technologies
Faire une évaluation de la disponibilité
stationnaire
Analyser la sécurité des systèmes.
Références
[48] [2] [1]
[48] [2] [1] [58]
[76]
Produits
tants
Produits
tants
Table 6.5 – Plan d’étude pour le serveur
Critères
4.3.1Performance
4.3.2Fiabilité
Évaluer la performance du serveur
Estimer la fiabilité de la solution
Références
[41] [53] [4]
[5] [41]
exisexis-
42
Table 6.7 – Plan d’étude pour l’interface
Critères
4.4.1Facilité d’utilisation
4.4.2Compatibilité
4.4.3Complexité
Évaluer selon la méthode de Nielsen et
Molich.
Déterminer selon la compatibilité avec
les différents systèmes d’exploitation.
Estimer selon le temps requis prévu
pour la conception.
Références
Consédérations
pratiques [32]
[38] [93] [33] [94]
[38] [93] [33] [94]
Table 6.9 – Plan d’étude pour les coûts
Critères
4.5.1Coûts matériels
Additionner les coûts matériels. Les
coûts de composantes intermédiaires ne
sont pas inclus
4.5.2Coûts d’opération
Estimer les coûts d’opération selon la
fiabilité.
Estimer les coûts de main-d’oeuvre. Les
côuts de développement (Modélisation
et Optimisation) ne sont pas inclus sauf
pour la programmation.
4.5.3Coûts de main-d’oeuvre
Références
[16] [17] [18] [23]
[28] [55] [34] [35]
[37] [52] [46] [47]
[47] [42] [43] [53]
[3] [41]
[26] [27] [24]
Table 6.11 – Composition du concept 1 - Projet Oxypod
Fonction
5.2.1.1Communication
5.2.1.2Stockage
5.2.1.3Contrôle
5.2.1.4Affichage
5.2.1.5Batterie
5.2.2Recharge
5.2.2.1Serveur
5.2.2.2SGBD
5.2.3.2Langage
5.2.3.1Interface
Concept 1
Cellulaire
SSD
PIC 24
ACL
Li-Ion
Intégrée
Amazon
MySQL
JAVA
GUI
43
000 heures. L’affichage ACL passif a comme avantage d’être une solution qui a déjà fait ses
preuves sur le marché. Selon le dispositif d’affichage ACL proposé, le modèle à une durée de
vie d’environ 100 000 heures. Puisque la mémoire de type FLASH a une fiabilité assez élevée
comme mentionné dans la section 5.2.1.2, le MTBF du module portable est donc celui de
l’écran ACL. Selon le barème de fiabilité, 11.42
= 1.14, cet affichage reçoit une note de 100%.
10
Autonomie électrique : Pour obtenir une bonne autonomie électrique, on doit choisir
un système avec une consommation minimale et une pile procurant une puissance maximale.
En ce qui concerne l’alimentation électrique du module portable, il a été déterminé que pour
le premier concept global, un assortiment de batteries lithium-ion sera utilisé. L’assortiment
de 4 batteries à 2600 mAH et un total de 14.8V procure une puissance de 38.48 Wh. Le système Oxypod contient de base le capteur de saturation en oxygène et le régulateur de débit
pour une consommation minimale de 3.1 watts. Le système de communication n’est pas inclus
dans le calcul, car il sera utilisé seulement pour une courte période durant la journée et sera
compensé par la consommation en mode « sleep ». La consommation du module portable,
soit le microprocesseur, l’écran ACL, la carte mémoire et le reste du circuit, est estimée à
1.7 watts. Son autonomie est donc de 8 heures au minimum. Selon la formule établie dans le
= 0.67, le critère a donc une note de 67%.
cahier des charges, 8−4
6
Temps de recharge : Le chargeur MPP-15 de la compagnie PEI-GENESIS est capable
de fournir un courant de charge égal à 800 mA avec une efficacité de 0.75%. Pour la batterie
Li-Ion de 2600 mAH, cela correspond à 0.31C. Le temps de recharge réel pour la pile Li-Ion
est donc de : 2600/(0.31 ∗ 2600)/0.75 = 4.33 heures.
Volume : Le volume total de ce concept peut s’adapter selon l’architecture qu’on décidera de donner au circuit du module. On peut donc croire que le volume ne sera pas trop
élevé, car le but sera de restreindre l’espace lors de la conception. Le volume du module IDM
est réellement faible, on prendra cette valeur de référence que l’on tentera de réaliser avec
notre module. Ceci ne devrait pas être difficile puisque l’écran ACL du concept est beaucoup
plus petit que celui de l’IDM. En ajoutant la batterie, le module de recharge, de mémoire
SSD, de communication GSM, l’écran ACL et les autres composantes, le concept aura ap450
= 0.82,
proximativement un volume de 450 cm3. On calcule donc le critère suivant, 1 − 2500
soit une note de 82%.
Poids : Comme pour le volume, le poids doit être estimé. La masse du circuit est donc
évaluée à 250 g avec le PIC24, pour un total de 790 g avec les autres composantes. Selon la
790
formule dans la section 4.1.5, 1 − 2500
= 0.68, le concept obtient une note de 68% pour le
poids du module portable.
6.2.3
44
Communication : Téléphonie cellulaire
Portée du transfert : Des technologies comme la technologie HSDPA (High Speed
Downlink Packet Access), qui sont apparues au courant de la troisième génération (3G), permettent une plus grande possibilité de contrôle de dispositifs à distance puisque la portée de
ces dernières s’étend sur plusieurs kilomètres. La valeur de référence par rapport à la portée
= 158, le
est de 30 kilomètres. En utilisant la formule du barème à la section 4.2.1, 30000−10
190
résultat obtenu est de 100%.
Vitesse de transfert : Les systèmes de communication par téléphonie cellulaire ont
évolué énormément. De nos jours, tous les appareils utilisant ce genre de réseau font partie
de la génération 3G, et plus (3e génération en montant). Ceci veut dire que les données
sont transmises à une vitesse allant de 600 kbps à plus de 20 000 kbps. En utilisant la formule du barème, nous pouvons évaluer que la vitesse minimale de 600 kbps, mesurée par
600−200
= 0.22 donne une note de 22%.
1800
Fiabilité de communication : La technologie qu’emploie la troisième génération (3G),
W-CDMA, permet une transmission optimale des données. Il est important de noter que la
bande de fréquence attribuée à la transmission des données est plus large. Ceci veut dire
que les données y circulent plus facilement et plus rapidement. De plus, le W-CDMA gère la
transmission de l’information par « paquets », c’est-à-dire que les données sont coupées en
petits groupes et sont ensuite transmis de manière optimisée sur le canal de communication
selon la disponibilité des canaux servant à la transmission. Cette disponibilité est évaluée à
99.9% et plus pour l’ensemble des systèmes de la troisième génération en montant. Avec la
= 0.95.
formule du barème, nous pouvons évaluer le résultat de la manière suivante : 99.9−98
2
Le résultat obtenu est donc de 95%.
Confidentialité des données : La téléphonie cellulaire est un système de communication qui permet une sécurité optimale à l’usager par rapport à ses données. En effet, chaque
usager est authentifié par des cartes SIM (R-UIM). L’encodage des données, qui est typique
de tous les standards CDMA fonctionne plus efficacement que les algorithmes de cryptographie utilisés par la plupart des réseaux de communication. Dans ce cas, on peut donc accorder
une note de 100% pour la confidentialité des données.
6.2.4
Serveur : Amazon Relational Database Service
Performance : Les serveurs d’Amazon, situés dans un nuage informatique, ont l’avantage, pour ce qui est des performances, de nous allouer automatiquement la puissance nécessaire au bon moment. En effet, le nombre de processeurs (ou d’instances dans les termes
d’Amazon) dédié à notre tâche augmente si notre demande en puissance est plus élevée et
Amazon nous chargera le temps d’utilisation de ses processeurs. La puissance disponible est
donc, en théorie, presque illimitée. C’est pour cette raison que la note de 100% sera accordée
à cette solution sur le plan des performances. Amazon comprend un système de gestion de
45
base de données de type MySQL.
Fiabilité du serveur : Pour ce qui est de la fiabilité, celle-ci est évaluée selon la disponibilité stationnaire. Ce concept a l’avantage de nous fournir des données exactes sur la
disponibilité stationnaire. Amazon nous avance une disponibilité stationnaire de 99.95% d’accès aux données. C’est excellent, car cela donne une note de 0.975 sur le plan de la fiabilité,
selon le cahier des charges.
6.2.5
Interface : Java
Facilité d’utilisation : Pour une description détaillée des points qui servent à évaluer
ce critère, voir le cahier des charges 4.4.1.Une interface graphique remplit le point 1 du critère, car les icônes et les options des menus correspondent aux tâches à effectuer. De plus,
le graphisme de ces outils de contrôle est naturel pour l’utilisateur (exemple : une disquette
pour enregistrer et une page blanche pour un nouveau document). Le point 2 est rempli,
car les interfaces graphiques sont très répandues. Le point 3 est également rempli, car les
interfaces graphiques permettent de conserver plusieurs fenêtres ouvertes et ainsi de laisser
l’information disponible pour l’usager. Le point 4 est rempli, car les médecins pourront utiliser les connaissances apprises dans d’autres logiciels médicaux ou des logiciels courants, les
GUI étant très répandus et présentant des caractéristiques communes. Le point 5 est rempli
à l’aide de rétroactions comme : " Voulez-vous vraiment supprimer ce fichier ? ", " Voulezvous continuer ? ". Le point 6 est rempli, car il est pratiquement toujours possible de fermer
une fenêtre inintéressante. Le point 7 est rempli, car les icônes permettent de d’effectuer des
tâches fréquentes rapidement, de même que les raccourcis clavier et les hyperliens. Le point 8
est rempli, les bons messages d’erreurs dépendent d’une programmation efficace et parce que
l’utilisateur a généralement accès à l’ordinateur local. Le point 9 est rempli, car il est possible de programmer le logiciel pour qu’il affiche des avertissements dans certaines conditions.
Les points sont tout remplis, donc selon le barème : 9/9 =1. Étant donné que le l’interface
web est un sous-type d’interface graphique, les résultats sont pratiquement identiques. À la
différence qu’il est impossible de prévenir les erreurs (point 9). L’interface web réagit aux
informations qu’envoie l’utilisateur, il ne peut l’avertir avant qu’il n’ait envoyé sa commande.
Selon le barème, la note est donc de 8/9.
Portabilité : Le fait que le Java soit un langage interprété le rend portable sur de nombreux systèmes d’exploitation parce que son interpréteur est très répandu sur les ordinateurs
actuels. Cela lui donne une note de 100% sur le plan de la portabilité.
Complexité : Le Java ne présente pas de notions complexes tels les pointeurs que l’on
voit en C/C++. Il existe de nombreuses librairies pour faciliter le développement. Il dispose
de « ramasse-miettes »et d’autres technologies afin de faciliter la vie du développeur. De plus,
il est orienté-objet. Tout cela contribue à le rendre simple et lui vaut une note de 100%.
6.2.6
46
Coûts
Coûts des matériaux : Voici une liste exhaustive des composantes utilisées pour ce
concept avec leur prix : batterie lithium-ion (55$), affichage ACL (12.70$), module SSD
(30$), PIC24 (6.72$), recharge intégré (85$). Le total du coût d’un module portable est
estimé à 200$, donc 20 000$ pour 100 modules. Le critère des coûts de matériaux obtient une
note de 90%, selon les barèmes du cahier des charges.
Coûts de main-d’oeuvre : Un technicien en génie électronique devra travailler pendant
approximativement 400 heures (4 heures par modules) initialement ce qui, pour un salaire
de 22.43$ de l’heure, se traduit par un montant de 8972$. De plus, un programmeur devra
réaliser l’interface graphique ce qui coûtera environ 3400$. Le total sera donc de 12 372$.
Cela donne une cote de 94% pour ce critère.
Coût d’opération : Le prix du service offert par Amazon est d’environ 100$/mois, ce qui
donne une facture de 1200$ pour une année. En faisant affaire avec la compagnie Motorola,
on peut obtenir un forfait de base de 20$ par mois. Si l’on accumule le montant pour 12 mois
et qu’on l’applique pour 100 clients, on obtient une facture de 24 000$. Le montant total du
coût d’opération est donc de 25 200$, soit une note de 50%.
6.3
Concept 2
6.3.1
Description
Dans le cadre du deuxième concept global, la solution proposée met l’accent sur un concept
regroupant plusieurs parties en même temps, soit le module intégré IDM (Intelligent Display
Module) de la compagnie Texas Instruments. Afin d’accompagner celui-ci, il a été décidé
qu’entre autres seraient utilisés un système de communication de type Wi-Fi, un serveur
local implanté à la clinique, de même que l’utilisation de cartes mémoire à même le module
IDM. La batterie désignée dans ce cas-ci est également de type lithium-ion couplé à une
recharge de type externe.
6.3.2
Module : concept 2
Fiabilité : Le module IDM est une solution haut de gamme dans les microcontrôleurs.
Cette solution est sous la forme tout-en-un. Les composants requis pour son fonctionnement
sont donc compatibles et ont été préalablement testés. Cela augmente le MTBF. Pour un
appareil de cette catégorie, il a été déterminé que le MTBF est d’environ 80 000 heures.
Cependant, l’écran tactile risque de réduire cette valeur, car il sont souvent à risque de briser
selon l’utilisation que l’on en fait. On estimera donc le MTBF de l’affichage à la moitié de la
= 0.57,
valeur de l’affichage ACL standard. Selon le cahier des charges, l’équation suivante 5.7
10
donne une note de 57% sur la fiabilité du module portable.
Autonomie électrique : Dans le cadre du deuxième concept, il a été décidé que le même
assortiment de batteries lithium-ion serait branché au module IDM. Selon les spécifications
47
Table 6.12 – Composition du concept 2 - Projet Oxypod
Fonction
5.2.1.2Stockage
5.2.1.3Contrôle
5.2.1.4Affichage
5.2.1.5Batterie
5.2.2Recharge
5.2.2.1Serveur
5.2.2.2SGBD
5.2.3.2Langage
5.2.3.1Interface
Concept 2
Wi-Fi
Carte Mémoire
IDM
Inclus
Li-Ion
Externe
Local
PostgreSQL
Python
GUI
du fabricant, le module IDM dissipe environ 1.5 watt de puissance. La consommation totale
du système permet donc une autonomie d’environ 8.4 heures. En suivant notre barème, on
= 0.73. La note obtenue pour cette partie est donc de 73%.
obtient la formule : 8.4−4
6
Temps de recharge : Le chargeur MPP-15 de la compagnie PEI-GENESIS est capable
de fournir un courant de charge égal à 800 mA avec une efficacité de 0.75%. Pour la batterie
Li-Ion de 2600 mAH, cela correspond à 0.31C. Le temps de recharge réel pour la pile Li-Ion
Volume : Puisque le volume du dernier concept a été estimé à partir du module IDM,
on estime retrouver environ le même volume, car les composantes utilisées sont semblables,
soit 350 cm3 sans le module de recharge. On obtient alors une note de 86%.
Poids : L’écran tactile ACL dans ce concept est beaucoup plus grand que celui utilisé
dans le dernier concept. On évalue que la masse ajoutée par ce dernier est de 100 g. Toutefois, le modèle n’a pas de module de recharge intégré. Le poids ajouté par l’écran est donc
compensé par celui du module de recharge. On peut consentir que le poids total du module
restera sensiblement le même. La même note de 68% est accordée à ce critère.
6.3.3
Communication : Wi-Fi
Portée du transfert : L’ensemble des normes de Wi-Fi couvrent un rayon variant de
25 à 5000 mètres. En utilisant la formule du barème de la section 4.2.1, nous avons que
25−10
= 0.079 vaut une note de 7.9%.
190
Vitesse de transfert : Comme la plupart des protocoles 802.11 qui sont utilisés de nos
48
jours, les vitesses de transfert se situent entre 6 Mbps et 150 Mbps. Il est possible d’évaluer
à l’aide de la formule du barème se trouvant à la section 4.2.2, si la vitesse minimale répond
au critère suivant : 6000000−200000
= 3.22. La communication de type Wi-Fi obtient une note
1800000
de 100%.
Fiabilité de communication : Comme on l’a vu à la section 5.2.1.1, il existe des révisions de la norme qui utilisent des méthodes d’accès CSMA/CA, méthodes qui envoient
un accusé de réception une fois les données transmises. De plus, les stations patientent lors
de l’envoi des données, empêchant ainsi toute collision. La disponibilité stationnaire d’un tel
système s’élève au-dessus de 99.5%. Avec l’équation du barème à la section 4.2.3, nous avons
= 0.75 donne une note de 75%.
que 99.5−98
2
Confidentialité des données : Comme nous l’avons vu ci-dessus, les différentes révisions de la norme 802.11 du Wi-Fi ont amélioré la sécurité par rapport aux versions initiales.
En effet, les versions récentes ont augmenté le processus d’authentification et de chiffrement.
De plus, il est facile d’optimiser cette sécurité avec un réseau privé virtuel ou RADIUS si
la révision utilisée du système semble avoir des failles. Il est donc difficile d’affirmer, après
toutes ces possibilités qu’il y a sur le marché, que le système de communication Wi-Fi n’est
pas un système sécuritaire. On lui attribue donc une note de 100%.
6.3.4
Serveur : Serveur local CybertronPC
Performance : Un serveur local tel que présenté à la section 5.2.2.1 serait utilisé comme
serveur de base de données. Un des avantages d’une telle implantation est que les médecins
auront un accès direct aux données via le réseau local de l’entreprise lorsqu’ils travailleront
à la clinique. Cela augmente la vitesse pour les médecins, permet de diminuer l’utilisation
d’internet et ainsi d’économiser de la bande passante. Un serveur tel que le « CybertronPC
XVA9080 Imperium Tower Server »propose deux processeurs « Intel Xeon Quad Core ». Chacun possède quatre coeurs de 2 GHz chacun. Cela donne un total de 16 GHz de puissance.
= 1.17, on obtient la note de 100% pour ce critère. Sur ce
Selon la formule du barème, 16−2
12
serveur, c’est PostgreSQL qui est installé pour la base de données.
Fiabilité du serveur : Pour ce qui est de la fiabilité, c’est assez difficile à évaluer. En
effet, il n’existe pas de données précises données par le fabricant et il y a de nombreuses
pièces. Cependant, dans ce concept, plusieurs moyens ont été pris afin d’augmenter la disponibilité stationnaire. Il y a, entre autres, l’utilisation d’un « raid »pour les disques, de la
mémoire-vive auto-correctrice et un onduleur. Grâce à cela, on peut estimer une disponibilité
totale d’environ 99%. Cela donne, selon la formule du barème, une note de 50%.
6.3.5
49
Interface : Python
Facilité d’utilisation : Pour une interface graphique, la note de 9/9 est donnée comme
c’est expliqué au concept 1 du présent chapitre 6.2.5.
Portabilité : Comme Python est un langage interprété, il peut être exécuté sur les systèmes d’exploitation les plus répandus et même certains qui sont plus rares, cela lui procure
une note de 100% pour le critère de portabilité.
Complexité : Le Python est fait pour être très facile à apprendre et à utiliser. De plus,
c’est un langage orienté objet, et son typage est dynamique. Il est donc très facile d’assigner
des variables et même de sauvegarder de multiples éléments dans une seule variable. Le résultat du critère est fixé à 100% à cause de sa simplicité.
6.3.6
Coûts :
Coûts matériels :Un module IDM comme celui que nous utilisons a un coût de 195.57$.
Une batterie lithium-ion, quant à elle, a un prix qui s’élève à 55$.Le système Wi-Fi, de son
bord, coûte 21.10$. Finalement, en ce qui concerne le serveur local, il est estimé à 325$ par
mois. À partir de ces informations, il est possible d’évaluer le montant total. En effet, puisqu’il
y a 100 modules à produire, le prix total des modules IDM va ête évalué à 19 557$. Puisqu’il
faut produire 100 modules, il faut produire 100 batteries lithium-ion. Le coût total va donc
s’élever à 5 500$. Comme la durée de la phase 1 d’Oxypod est de un an (donc douze mois), le
montant du serveur va être multiplié par douze, et il a une valeur de 3 900$. En additionnant
le tout, il est possible d’estimer le coût matériel du concept à 28 978.1$. En utilisant la
vaut
formule du barème fixée à la section 4.5, il est possible de constater que 200000−28978.1
200000
0.855. Cela veut dire que le critère est respecté.
Coûts d’opération : Un serveur local Cybertron PC coûte approximativement 3900$
par année, et il est à noter que MySQL est inclus dans ce dernier. En insérant ce montant
dans la formule du barème définie à la section des coûts du cahier des charges (section 4.5),
voici ce qu’il se passe : 50000 − 390050000 = 0.922. Le critère est donc respecté.
Coûts de main-d’oeuvre : Le technicien informatique qui fabrique le module est payé
22.43$ de l’heure. La durée du travail qu’il a effectué est estimée à 4 heures. Puisqu’il y a
100 modules à préparer, le montant s’élève à 8 972$. À ce prix s’ajoute le montant qui doit
être versé au programmeur, pour réaliser l’interface graphique. Le montant minimal qui peut
être versé pour une telle tâche est de 20.75$ de l’heure. Le temps requis pour la réaliser est
environ 2 heures. Puisqu’il y a 100 modules, le prix s’élève à 3 400$. Le montant total de la
main-d’oeuvre est donc estimé à 13 122$. La formule du barème présentée à la section 4.5
vaut 94%, ce qui veut dire que le critère est respecté.
dit que 200000−12372
200000
50
6.4
Concept 3
6.4.1
Description
La troisième solution globale proposée tourne autour du processeur ARM. Cette solution
de contrôle est de loin la plus haut de gamme. Pour ce concept, il a été décidé que nous
utiliserons le système de communication Zigbee, une ou plusieurs cartes mémoire, un serveur
local, de même qu’une alimentation assurée par une batterie de type lithium-ion. La recharge
de cette dernière sera interne (intégrée), c’est-à-dire que le patient n’aura qu’à brancher
directement le module à une prise murale.
Table 6.14 – Composition du concept 3- Projet Oxypod
Fonction
5.2.1.2Stockage
5.2.1.3Contrôle
5.2.1.4Affichage
5.2.1.5Batterie
5.2.2Recharge
5.2.2.1Serveur
5.2.2.2SGBD
5.2.3.2Langage
5.2.3.1Interface
6.4.2
Concept 3
ZigBee
Carte Mémoire
ARM
ACL
Li-Ion
Intégrée
Local
Oracle
Python
Interface web
Module : concept 3
Fiabilité : Le processeur ARM est une solution très performante en ce qui a trait au
projet Oxypod. Les solutions de système embarqué fourni par la compagnie Thecnologic Systems sont toutes modulaires, on peut se demander alors si cela peut avoir un impact sur la
qualité des pièces. Selon le rapport fourni sur le test de HALT, les composantes utilisées par
la compagnie Technologic Systems sont de très haute qualité. Les tests de température et
de vibration ont démontré qu’il peuvent endurer des contraintes assez élevées. On considère
donc que le MTBF sera encore une fois le même que celui de l’écran ACL, soit la même note
de 100%.
Autonomie électrique : Pour le troisième concept, il a été décidé que le même assemblage de batterie lithium-ion sera utilisé. Étant donné que le module TS-7350 dissipe
seulement 2 Watts et que les quatres batteries fournissent un total de 38.48 Wh, il a été
calculé que l’autonomie d’un tel module est approximativement de 7.5 heures. Donc, d’après
les formules du cahier des charges, on a : 7.5−4
= 0.58, ce qui fait en sorte que cette solution
6
51
décroche une note de 58%.
Temps de recharge : Le chargeur DTC-60 de la compagnie PEI-GENESIS est capable
de fournir un courant de charge de 2600 mA avec une efficacité de 80%. Pour la batterie
Ni-MH de 4500 mAH, cela correspond à 0,57C. Le temps de recharge réel pour la pile Li-Ion
est donc de : 4600/(0,57 ∗ 4500)/0,80 = 2.20 heures.
Volume : L’idée d’utiliser des périphériques modulaires est très intéressante, car il réduit
considérablement le temps d’assemblage des modules portables et en même temps les coûts
associés à la main-d’oeuvre. Cependant, l’espace utilisé augmente fortement à chaque module
ajouté. Puisque la plupart des fonctionnalités sont incluses sur le TS-7350, le seul module
qu’on doit ajouter est celui du système de communication « Zigbee ». Le volume devient
alors le double du module de base, soit 596 cm3. En ajoutant l’écran ACL, la batterie et le
module de recharge intégré, on parvient à un volume total de 841 cm3. La note accordée est
par conséquent de 66%.
Poids : Étant donné qu’aucune donnée n’est fournie sur le poids, on considère que le
poids global des deux modules sera environ le double de celui estimé pour le circuit dans le
premier concept, c’est-à-dire une masse de 400 g. L’ajout des autres composantes fait grimper
le poids total à 940 g. Ce critère reçoit une note de 62%.
6.4.3
Communication : Zigbee
Portée du transfert : Le système de communication ZigBee a 100 mètres, comme valeur
de référence en ce qui a trait à sa portée. Si cette valeur est insérée dans l’équation suivante,
100−10
= 0.47, on obtient alors une note de 47%.
190
Vitesse de transfert : Le concept ZigBee, comme nous l’avons vu ci-dessus a également une valeur de référence minimale en ce qui a trait à sa vitesse de transfert. Cette
valeur est de 250 kbps. Si nous insérons cette dernière dans la formule du barème, située à la
section 4.2.2, nous obtenons que 250−200
vaut 0.0277. Cela veut dire que le critère est respecté.
1800
Fiabilité de communication : En ce qui concerne la fiabilité, puisque le ZigBee utilise
également une méthode d’accès CSMA/CA, nous pouvons affirmer qu’elle est assez fiable et
que sa disponibilité stationnaire est évaluée à 99.5%, comme dans le cas du Wi-Fi. Puisque
la valeur de cet estimé est la même que celle de l’estimé du Wi-Fi, on obtient la note de 75%
pour ce critère.
Confidentialité des données : Pour ce qui est de la sécurité, comme exposé à la section
5.2.1.1, elle n’est à la base pas optimale, mais il y a moyen de l’optimiser et de la rendre
adéquate pour le système Oxypod. En effet, à la base, le niveau de chiffrement n’est pas très
élevé pour ce genre de réseau. Cependant, en augmentant la puissance de la puce, la qualité
52
des composants, du générateur et du codage, il est possible d’utiliser un ZigBee sécuritaire.
On lui assigne donc une valeur de 50% des objetifs de confidentialité, car elle n’est pas une
solution automatiquement sécuritaire.
6.4.4
Serveur : Serveur local CybertronPC
L’évaluation des critères pour le serveur physique local a déjà été établie dans la même
section pour le deuxième concept. Cependant, c’est le SGBD 1 Oracle qui est installé.
6.4.5
Interface : Python
Les critères exposés sur le langage Python ont déjà été discutés à la dernière section. Les
résultats resteront les mêmes. Pour une interface web, la note de 8/9 est donnée comme c’est
expliqué au concept 1 du présent chapitre 6.2.5.
6.4.6
Coûts :
Coûts des matériaux : Tel que mentionné précédemment, le concept comprend un
module TS-7350 (129$), un écran ACL(12.70$), une carte mémoire SD (10$), une batterie
lithium-ion (55$), le module zigBee interne ainsi que le module zigBee externe(171$) et le
module de recharge(85$). Cela donne un prix pour le module de 462$. De plus, le coût pour
l’acquisition du serveur est de 2 974$. Donc, en additionnant le coût des 100 modules au coût
du serveur on obtient un coût des matériaux de 49 244 $. Selon le barème la côte obtenue
pour ce coût sera donc de 0,755 ce qui se traduit par une attribution de 3.775 % pour le critère.
Coûts de main-d’oeuvre : Puisque la solution modulaire est pratiquement montée au
complet, on estime que chaque module prendra maximum 1 heure de travail. C’est donc dire
que le même salaire de 22.43$ de l’heure se traduit par un montant total de 2243$. On ajoute
avec cela le 12 372$ pour la programmation. Une note de 92% lui est attribuée.
Coûts d’opération : Finalement, les coûts d’opération seront composés des différents
coûts liés au serveur. La batterie du serveur sera remplacée à environ chaque quatre ans, son
coût par année sera donc de 346/4 = 86.5. De plus, le coût pour payer un employé pour
les différents bris ou maintenances du serveur sera d’environ 1500$ par année. Le coût pour
Oracle pour deux processeurs est de 586$ par an. Au total, le coût serait de 2172.5$. Le
concept reçoit donc une note de 0.96 et 4.8% pour ce qui est du critère.
1. Système de gestion de base de données
53
6.5
Concept 4
6.5.1
Description
Le quatrième concept global proposé a pour but principal d’analyser une solution comportant sur les autres technologies offertes qui n’ont pas été considérées jusqu’à maintenant.
Les nouveaux concepts ajoutés sont donc l’affichage OLED, la batterie Ni-Mh et le serveur
à distance dédié.
Table 6.16 – Composition du concept 4- Projet Oxypod
Fonction
5.2.1.2Stockage
5.2.1.3Contrôle
5.2.1.4Affichage
5.2.1.5Batterie
5.2.2Recharge
5.2.2.2Serveur
5.2.2.2SGBD
5.2.3.2Interface
5.2.3.1Interface
6.5.2
Concept 4
Wi-Fi
SSD
PIC 24
OLED
NI-MH
Externe
Serveur dédié distant
MySQL
JAVA
Interface web
Module : concept 4
Fiabilité : La technologie OLED est plus récente que celle des écrans ACL, mais leur
qualité de fabrication et leur durabilité sont d’autant plus excellentes. Puisque le contrôleur
PIC24 et le module sont réutilisés pour ce concept, on prend en considération que le MTBF
reste sensiblement le même. On lui accorde donc directement une note de 100%.
Autonomie électrique : La prochaine solution se concentre sur les 10 batteries Nickelhydrure métalliques de 1.2V et 4500 mAh chacune. Ce type de batterie a une durée de vie
supérieure à plusieurs autres types de batteries et la totalité de la pile offre une puissance
considérable de 54 Wh. Le concept a une dépense énergétique similaire au premier concept,
soit 4.8 W. L’autonomie des batteries est alors de 11.25 heures. D’après la formule du cahier
des charges, on a 11.25−4
= 1.2. Cette solution obtient donc la valeur maximale de 100%.
6
Temps de recharge : Le chargeur DTC-60 de la compagnie PEI-GENESIS est capable
de fournir un courant de charge de 2600 mA avec une efficacité de 80%. Pour la batterie
Ni-MH de 4500 mAH, cela correspond à 0.57C. Le temps de recharge réel pour la pile Li-Ion
54
Volume : Le volume de 450 cm3 estimé au premier concept incorpore les batteries lithiumion. En changeant ce type de batterie pour des nickel-hydrures métalliques, on obtient un
nouveau volume de 609 cm3. La note du critère pour le volume devient donc 76%.
Poids : En reprenant le même principe de calcul effectué pour le volume, on obtient une
masse module pour le module de 1074 g, ce qui en fait la solution la plus lourde. La note
attribuée à ce critère est donc de 57%.
6.5.3
Communication : Wi-Fi
Le système de communication du concept 4 est le même que celui du système deuxième
du concept. Les résultats des critères obtenus seront par conséquent les mêmes.
6.5.4
Serveur : Location serveur distant dédié
Performance : Le service offert par la compagnie Netissime qui a retenu notre attention
est la location d’un serveur distant situé en France. Il offre sur le plan des performances, un
processeur « Intel Xeon dual core »de 3 GHz. Cela donne, de cette manière, une puissance de
= 0.33, nous
calcul totale de 6 GHz. Selon la formule adoptée dans le cahier des charges, 6−2
12
obtenons du côté de la performance une note de 33%. Le gestionnaire de base de données
MySQL est compris et installé.
Fiabilité du serveur : Sur le plan de la fiabilité, le fait de faire affaire avec une compagnie spécialisée nous permet d’avoir les chiffres. Une disponibilité stationnaire de 99.9% est
= 0.95, une note de 95% pour le critère
donnée. Cela donne avec la formule suivante 99.9−98
2
de la fiabilité.
6.5.5
Interface : JAVA
La partie JAVA est déjà évaluée dans le premier concept. On transposera les mêmes résultats dans le tableau de synthèse. Pour une interface web, la note de 8/9 est donnée comme
c’est expliqué au concept 1 du présent chapitre 6.2.5.
6.5.6
Coûts :
Coût matériel : Pour le quatrième concept, voici la liste des composantes du module
ainsi que leur prix : le module de communication WI-FI (21.10310$), la carte de stockage
SSD (30$), le contrôleur PIC 24 (6,72$), l’affichage OLED (33.78$) ainsi que les batteries
55
NI-MH (70$). De plus, il faudra acheter un modem Wi-Fi (50$) Le coût total du module
portable complet est évalué à 221.60 $ par module. Ce qui donne un total de 22 160.31 $
pour la production de 100 modules portables. On obtient alors une note de
Coût main-d’oeuvre : Étant donné que les composantes électroniques sont pratiquement les mêmes que le concept 1, le temps et le coût de montage sera le même, soit 12 372$.
Coût d’opération : Il n’y a qu’un seul coût pour l’opération du système, il s’agit de la
location du serveur. Le montant s’élève à 3900$ par an.
6.6
Synthèse des résultats
La synthèse des résultats regroupe sous forme de tableau les résultats obtenus à chacun
des critères selon les quatre concepts établis. On peut donc connaître l’effet individuel d’un
concept sur les critères qui le concerne. Le tableau 6.18 présente les valeurs trouvées.
6.7
Matrice de décision
La matrice de décision réunit les mêmes données que le tableau de synthèse, mais cette
fois-ci, ce dernier a été pondéré selon les grandeurs proposées dans le tableau 4.1 du cahier
des charges. L’information fournie par ces tables donne une vision globale du concept proposé
et aide à prendre une meilleure décision définitive.
6.8
Interprétation des résultats
En observant le tableau 6.20, il est évident que les concepts qui se démarquent en termes
de pourcentages élevés sont les concepts 1 et 4. En effet, les deux concepts ont environ 83%
au total, en ce qui a trait au taux de critères satisfaits. De plus, on voit que les concepts
deux et trois ont une dizaine de pour cent en moins et sont plus faibles notamment dans la
section module portable, une section qui est primordiale, car le bien-être du patient est au
coeur des besoins du projet. Cependant, en comparant ces deux concepts, on peut remarquer
que certaines des données ne sont pas rendues explicites par les barèmes choisis puisque le
poids et le volume du concept 4 sont beaucoup plus grands que pour le concept 1 alors que la
portée ainsi que la simplicité d’utilisation du concept 1 favorisent d’autant plus cette première
solution. Malgré les coûts plus élevés du concept, nous jugeons que le concept 1 rencontrera
davantage les besoins et exigences de la clinique et des usagers. Dans le prochain chapitre, il
sera exposé de manière plus détaillée la prise décision du concept retenu.
56
Table 6.18 – Synthèse de l’étude préliminaire des concepts du projet
Oxypod
4.1 Module portable
4.1.1 Fiabilité du module [heures]
4.1.2 Autonomie électrique [heures]
4.1.3 Temps de recharge [heures]
4.1.4 Volume [cm3 ]
4.1.5 Masse [g]
4.2 Communication
4.2.1 Portée du transfert [m]
4.2.2 Vitesse du transfert [kbps]
4.2.3 Fiabilité du réseau [%]
4.2.4 Confidentialité des données [%]
4.3 Serveur
4.3.1 Performances [GHz]
4.3.2 Fiabilité [%]
4.4 Interfaces
4.5 Coûts
4.5.1 Coûts matériels [$]
4.5.2 Coûts d’opération [$/an]
4.5.3 [$/an] Coûts de main-d’oeuvre
Concept 1
Concept 2
Concept 3
Concept 4
100000
8
4.33
450
790
57 000
8.4
4.33
350
790
100000
7.5
2.2
841
940
100000
11.25
2.2
609
1074
30000
600
99.9
100
25
6000
99.5
100
100
250
99.5
50
25
6000
99.5
100
illimitée
99.95
16
99
16
99
6
99.9
9/9
100
100
9/9
100
100
8/9
100
100
8/9
100
100
20 000
13 200
12 372
28 978
3 900
13 122
49 244
2 172.5
12 372
22 160
3 900
12 372
57
Table 6.20 – Matrice de décision du projet Oxypod phase 1
4.1 Module portable
4.1.1 Fiabilité du module
4.1.2 Autonomie électrique
4.1.3 Temps de recharge
4.1.4 Volume
4.1.5 Masse
4.2 Communication
4.2.1 Portée du transfert
4.2.2 Vitesse du transfert
4.2.3 Fiabilité du réseau
4.2.4 Confidentialité des données
4.3 Serveur
4.3.1 Performances
4.3.2 Fiabilité
4.4 Interfaces
4.5 Coûts
4.5.1 Coûts matériels
4.5.2 Coûts d’opération
4.5.3 Coûts de main-d’oeuvre
Total
Pond.
37%
8%
8%
5%
8%
8%
24%
5%
5%
7%
7%
14%
4%
10%
10%
4%
4%
2%
15%
5%
5%
5%
100%
Concept 1
26.99
8
5.44
1.52
6.56
5.47
19.75
5
1.1
6.65
7
13,75
4
9.75
10
4
4
2
13
4.5
3.7
4.8
83.5
Concept 2
24.27
4.56
5.84
1.52
6.88
5.47
17.82
0.57
5
5.25
7
9
4
5
10
4
4
2
13.58
4.28
4.6
4.7
74.7
Concept 3
26.33
8
4.64
3.45
5.28
4.96
10.33
1.44
0.14
5.25
3.5
13,75
4
9.75
10
3.55
4
2
13.28
3.78
4.7
4.8
73.25
Concept 4
30.1
8
8
3.45
6.08
4.56
17.8
0.57
5
5.25
7
10,82
1.32
9.5
10
3.55
4
2
13.85
4.45
4.6
4.8
82.15
Chapitre 7
Concept retenu
Ce chapitre est le résumé du rapport dans son entier, soit le concept le plus avantageux
parmi ceux présentés au chapitre 6 sur l’étude préliminaire. Cette partie présente donc en
détail les spécifications du système proposé, de même que son coût approximatif. De plus,
cette section inclut une documentation complète de la solution finale. La figure 7.1 présente
le concept dans son ensemble.
7.1
Présentation du concept retenu
La solution retenue est celle présentée à la section du chapitre 6 sous le nom de Concept1.
Cette solution inclut les composants suivants :
Module
– Microcontrôleur PIC 24
– Affichage ACL
– Mémoire SSD
– Batterie Lithium-ion
– Recharge intégrée
Communication
– Système de communication par téléphonie cellulaire
Serveur
– Serveur « Amazon Relational Database Service »
– SGBD 1 de type MySQL (fourni avec le serveur)
Interface
– Interface conviviale codée en JAVA
1. Système de gestion de base de données
58
CHAPITRE 7. CONCEPT RETENU
7.1.1
Spécifications du concept retenu
7.1.1.1
Module Portable
59
Le module portable aura comme tâche de faire le traitement et l’envoi des données nécessaires à la régulation du taux d’oxygène dans le sang en étant relié à une valve contrôlant
l’apport d’oxygène. Le module assurera de plus un lien bidirectionnel entre le patient et le
médecin pour le partage de donnée dans un sens et la modification de la consigne dans l’autre.
Le tout sera assuré à l’aide d’un dispositif léger et peu volumineux que l’utilisateur pourra
facilement avoir sur lui en tout temps.
D’abord, notre module assurera le traitement des données à l’aide d’un PIC24, un microcontrôleur simple et peu coûteux qui possède tout de même toute la puissance de calcul
nécessaire non seulement pour l’exécution des tâches nécessaires à la phase actuelle du projet,
mais aussi pour les phases ultérieures. Les données reçues par les senseurs seront envoyées sur
une mémoire de type SSD. Une méthode de stockage qui consomme peu, résistante et fiable.
Un simple module de communication à l’intérieur du module permettra alors le transfert des
données gardées en mémoire sur le SSD et de les faire parvenir au réseau cellulaire et ultimement, à la clinique. Cela sera réalisé automatiquement, sans que l’utilisateur ait a appuyer
sur une touche et qui ne soit pas dépendant de la présence à domicile de la personne pour
initier le transfert. Pour permettre au patient d’avoir une idée de l’état du module, un écran
ACL est inclus sur le module. Celui-ci affichera notamment l’état de charge de la batterie, le
niveau d’oxygène, ainsi que les diverses alarmes visuelles servant à communiquer toute autre
information à l’utilisateur.
Le système d’affichage des paramètres, tout comme l’ensemble des composantes, sera
fonctionnel dans des températures variant d’environ -20◦ C à 70◦ C, ce qui permettra de bien
s’accomoder à la situation québecoise ainsi qu’éventuellement à celle de d’autres régions du
globe. La recharge intégrée rend ce module d’autant plus portable puisque la recharge sera
possible dès que l’utilisateur se trouvera près d’une prise de courant au lieu de dépendre d’une
borne de recharge stationnaire. La batterie quant à elle fournie une autonomie électrique de
8 heures, ce qui devrait pouvoir convenir à une journée de travail moyenne avec la possibilité
de le recharger aisément durant la journée.
Compte tenu de la petite taille et la légèreté du module, il sera aisé de rajouter des
composantes et fonctionnalités dans les phases ultérieures du projet sans contrevenir aux
attentes et critères fixés ou fournis par la clinique Oxygénia.
7.1.1.2
Communication
Comme on l’a vu ci-dessus, le système de communication entre le module portable et
le serveur est important pour permettre, en premier lieu, au médecin de suivre le patient à
distance et d’assurer le transfert sans fil des données sauvegardées vers la base de données
jusqu’à la résidence du patient. Pour être en mesure d’effectuer ces tâches tout en satisfaisant
60
certaines exigences bien précises, le concept qui a été retenu est celui de la communication
par téléphonie cellulaire.
Afin d’être à jour sur la technologie et pour avoir une transmission fiable des données,
ainsi qu’un débit de transmission plus élevé, nous allons utiliser un système de la troisième
génération. Le module H24 de Motorola est idéal pour l’Oxypod. Tout d’abord, sa technologie HSDPA (High Speed Downlink Packet Access) permet davantage au médecin de contrôler
les dispositifs des patients à distance. Cela est dû au fait que la portée de cette technologie
est grande et s’étale sur des kilomètres. Puisque le débit de transmission est assez élevé, les
données du patient vers le médecin et du médecin vers le patient sont transférées dans de
petits délais. De plus, le transfert doit être fiable et réseau le réseau de téléphonie mobile est
donc une bonne solution. En effet, comme on l’a vu ci-dessus, puisque la bande de fréquence
attribuée à la transmission des données est plus large dans le cas des systèmes de la troisième
génération en montant, ces dernières y circulent plus facilement et la transmission se fait
par blocs, ce qui permet au canal de communication de transférer de manière optimisée les
données, en fonction de la disponibilité des canaux servant à la transmission. La téléphonie
cellulaire permet aussi un transfert confidentiel des données puisqu’à travers cette dernière,
chaque usager a une authentification par des cartes SIM (ou R-UIM) qui permettent un encodage plus optimal des données que les algorithmes de cryptographie. Le module H24 inclut
déjà cette carte.
Au Québec, il y a une grande variété de compagnies qui fournissent le système de communication par téléphonie cellulaire. Parmi eux, on retrouve notamment Bell, Fido, Rogers,
et Telus. Tous les quatre utilisent déjà les modules Motorola, ce qui donne un bon choix de
fournisseur. Pour les entreprises de plus grande envergure et qui aimeraient prendre de l’expansion, il est préférable d’utiliser Bell puisque c’est le réseau le plus répandu. Pour terminer,
il faut observer que non seulement un système de communication par téléphonie cellulaire
permet de satisfaire tous les besoins et les contraintes du client, mais il permet également de
s’étaler encore plus géographiquement grâce à sa portée, ce qui aiderait éventuellement au
développement des phases ultérieures.
7.1.1.3
Serveur
Le serveur de base de données sert de pont entre l’interface du médecin et le module
portable. On y entrepose différentes données qui sont nécessaires à l’interface du médecin
comme source de données. Ce type de fonctionnement est une architecture client/serveur très
répandue dans l’industrie. Le programme fait des requêtes SQL 2 à la base de données pour
accéder aux données. Le programme peut même modifier des informations si l’utilisateur
a la permission de le faire, tel que la modification de la consigne du taux de saturation
d’oxygène dans le sang. Les modules portables, de leur côté, vont aussi utiliser des requêtes
SQL afin d’ajouter des enregistrements et s’assurer que la consigne de saturation du taux
2. Structured Query Language
61
d’oxygène n’a pas été modifiée afin de respecter les consignes du médecin. Le tout sera
fait sur un serveur virtuel de base de données. Le tout sera dans un nuage informatique.
C’est un service informatique de la compagnie Amazon qui se nomme « Amazon Relational
Database Service ». Cette solution évite le déploiement d’équipements à la clinique et évite
d’avoir à entretenir cet équipement via l’embauche de personnel qualifié dans le domaine
de l’informatique. En plus de nous éviter plusieurs soucis, une telle solution est plus fiable
qu’un serveur physique et moins coûteuse que la location d’un serveur dédié. Un système de
gestion de base de données performant, MySQL, est fourni gratuitement pour nos besoins et
la facturation se fait sur le calcul de notre utilisation des services.
7.1.1.4
Interface
Pour l’interface, le choix du langage Java s’est imposé. En effet, le langage Java est très
répandu et il existe de nombreux programmeurs-analystes Java tandis qu’il peut être plus
difficile de trouver un programmeur python de qualité. Une interface graphique sera créée
afin de faciliter l’utilisation par les médecins et le programme pourra être portable sur de
nombreux systèmes d’exploitation.
7.1.2
Description des coûts
Selon le tableau 6.20, on voit que le concept 1 est celui qui est le plus gagnant. On n’explique cela par le fait que les coûts matériels sont moins élevés que des solutions embarquées
finies. Le concept implique des composantes électroniques individuelles, donc moins chers à
l’achat. Le prix d’un module s’élève à 200$ ce qui est raisonnable pour un équipement médical. Leur prix pourrait être davantage réduit par l’achat d’une plus grande quantité de pièces
dans les phases ultérieures du projet.
L’achat de composantes individuelles augmente cependant le prix de la main-d’oeuvre,
soit à 12 372$. Les estimations des prix de main-d’oeuvre n’incluaient pas les salaires de
développement (modélisation et optimisation). Le prix total pour les 100 modules est donc
de 32 372$. Un prix raisonnable compte tenu pour un design à faible exemplaire.
Les coûts d’opération sont les plus élevés des trois concepts étant donné les frais d’accès
au réseau. La décision de prendre un système de communication par téléphonie cellulaire
était un choix pour faciliter l’utilisation du module portable autant pour le patient que pour
le médecin.
Figure 7.1 – Diagramme physique du concept retenu
62
Bibliographie
[1] Adaptive Module, F4414 : H24 HSPA Module ,[En ligne].
http://www.adaptivemodules.co.uk/index.cfm/fa/shopdetails/Product_ID/
651/Category_ID/15 Page consultée le 14 avril 2011
[2] Alain Dessureault, Innovations technologiques- TIC,[En ligne].
http://www.icriq.com/fr/productique_tfp/sans_fil_2006_05_16.html Page
consultée le 8 mars 2011
[3] Amazon, Amazon Web Services Simple Monthly Calculator, [En
ligne].http://calculator.s3.amazonaws.com/calc5.html Page consultée le 13 mars
2011
[4] Amazon, Relational Database Service (Amazon RDS), [En
ligne].http://aws.amazon.com/fr/rds/ Page consultée le 13 mars 2011
[5] Amazon, Amazon Elastic Compute Cloud (Amazon EC2), [En
ligne].http://aws.amazon.com/fr/ec2/ Page consultée le 13 mars 2011
[6] APC, APC Smart-UPS 2200VA LCD 120V, [En ligne]. http://www.apc.com/
products/resource/include/techspec_index.cfm?base_sku=SMT2200 Page
[7] Brian Raiter, An eight-instruction turing-complete programming language, [En ligne].
http://www.lex-electronica.org/articles/v11-1/mian.pdf Page consultée le 12
mars 2011
[8] Calipia, Oracle, SQL Server,Quel SGBD en environnement Windows ?, [En ligne].
http://calipia.com/sql/SqlOracle.pdf Page consultée le 9 mars 2011
[9] CELL-CON, Model 452115-NA, NiMH / NiCd, 2 wire fast, smart charger, [En ligne].
http://cellcon.thomasnet.com/item/nimh-nicd-smart-charger-16w-2/nimhnicd-smart-charger-16w/452115-na? Page consultée le 12 avril 2011
[10] CELL-CON, Model 452240-LC, Lithium Ion, Lithium Polymer Charger, 1.3A, [En
ligne]. http://cellcon.thomasnet.com/item/lithium-ion-lithium-polymercharger-1-3a-2/lithium-ion-lithium-polymer-charger-1-3a/452240-lc? Page
consultée le 12 avril 2011
[11] Christophe Nowicki, Présentation du standard ZigBee, [En ligne].
http://www.csquad.org/tag/zigbee/ Page consultée le 14 mars 2011
63
BIBLIOGRAPHIE
64
[12] Comment ça marche, La mémoire vive (RAM ou mémoire PC), [En ligne].
http://www.commentcamarche.net/contents/pc/ram.php3 Page consultée le 11
mars 2011
[13] Comment ça marche, Onduleur, [En ligne].
http://www.commentcamarche.net/contents/protect/onduleur.php3 Page
[14] Comment Ça Marche ?, WiMAX-802.16-Worldwide Ineteroperability For Microwave
Access, [En ligne].
http://www.commentcamarche.net/contents/wimax/wimax-intro.php3 Page
[15] Comment Ça Marche ?, Téléphonie mobile,[En ligne].
http://www.commentcamarche.net/contents/telephonie-mobile/reseauxmobiles.php3 Page consultée le 15 mars 2011
[16] Crystalfontz America, Inc., CFAG16032C-YYH-TT , [En ligne].
http://www.crystalfontz.com/product/CFAG16032CYYHTT Page consultée le 12
avril 2011
[17] Crystalfontz America, Inc., CFAL12864Z-G-B2 , [En ligne].
http://www.crystalfontz.com/product/CFAL12864ZGB2.html Page consultée le 12
avril 2011
[18] CrystalfontzAmerica, Graphic LCD,[En ligne].
http://www.crystalfontz.com/products/index-ser.htmlPage consultée le 13 mars
2011
[19] CrystalfontzAmerica, OLED Modules, [En ligne].
http://www.crystalfontz.com/products/index-ser.html, Page consultée le 13
mars 2011
[20] Cybertron, Cybertron International, Inc. - Small and Medium Business , [En ligne].
http://www.cybertronpc.ca/
customkititems~kc~SVIIB181~Group~BUSINESS~Cat~SERVERS.htm Page consultée le
11 mars 2011
[21] Daniel Liang, Introducing to Programming with C++,Comprehensive, 1ère
édition,Prentice Hall, 2007, ISBN-13 :978-0132254458,643 pages.
[22] David Maume, SQLite devient la base de données standard du Web déconnecté, [En
ligne]. http://pro.01net.com/editorial/372465/sqlite-devient-la-base-dedonnees-standard-du-web-deconnecte, Page consultée le 11 mars 2011
[23] Digi-Key Corporation, SanDisk CompactFlash Memory Card, OEM Manuel product,
[En ligne]. http://media.digikey.com/pdf/Data%20Sheets/MSystems%20Inc%20PDFs/SanDisk%20CompactFlash%20Memory.pdf page consultée le
15 mars 2011
[24] Emploi Québec, Programmeurs/programmeuses et développeurs/développeuses en
médias interactifs (2174), [En ligne].
BIBLIOGRAPHIE
[25]
[26]
[27]
[28]
[29]
[30]
[31]
[32]
[33]
[34]
[35]
[36]
[37]
65
http://imt.emploiquebec.net/mtg/inter/noncache/contenu/asp/mtg122_
statprof_01.asp?PT4=53&aprof=2174&pro=2174&PT2=21&lang=FRAN&Porte=
1&cregncmp1=QC&cregn=QC&tri=01&PT1=1&type=01&motpro=programmeur&PT3=10
page consultée le 15 mars 2011
François Parmentier, PostgreSQL - Fiche logiciel validé PLUME, [En ligne].
http://www.projet-plume.org/fiche/postgresql, Page consultée le 8 mars 2011
Institut de la statistique du Québec, 307 - TECHNICIEN EN GÉNIE, [En ligne].
http://www.stat.gouv.qc.ca/donstat/societe/march_travl_remnr/remnr_
condt_travl/emploi_repere/307empl.htm page consultée le 15 mars 2011
Institut de la statistique du Québec, 308 - TECHNICIEN EN INFORMATIQUE, [En
ligne]. http://www.stat.gouv.qc.ca/donstat/societe/march_travl_remnr/
remnr_condt_travl/emploi_repere/308empl.htm page consultée le 15 mars 2011
Hitachi Global Storage Technologies, Hitachi Family of Microdrives, [En ligne].
http://www.hitachigst.com/tech/techlib.nsf/techdocs/
F532791CA062C38F87256AC00060DD49/\protect\T1\textdollarfile/
HGSTFamilyOfMicrodrives.pdf page consultée le 15 mars 2011
John Locke, WiFi - Cours d’introduction,[En ligne].
http://www.commentcamarche.net/faq/3020-wifi-cours-d-introduction Page
consultée le 8 Mars 2011
Leslie Lamport, LATEX : A document Preparation System, 2e édition, Addison Wesley
Professional, 1994. ISBN 0–201–52983–1.
Le Wimax, Haute vitesse Nomade Sympatico : Un gigantesque réseau Wimax pour le
Canada, [En ligne]. http://www.wimax-fr.com/Haute-vitesse-Nomade-SympaticoUn-gigantesque-reseau-Wimax-pour-le-Canada/
LEWIS, Clayton et Rieman, John, Task-Centered User Interface Design,[En ligne],.
http://hcibib.org/tcuid/chap-4.html#t2 page consultée le 15 avril 2011
Marc LUTZ, Learning Python : Powerful Object-Oriented Programming,4e édition,
O’Reilly Media, 2009, ISBN-13 :978-0596150864,1216 pages
Microchip Co., 8-bit microcontroller, [En ligne]. http://www.microchip.com/
stellent/groups/picmicro_sg/documents/devicedoc/en023527.pdf Page
Microchip Co., DM180021 - MPLAB Starter Kit for PIC18F MCU , [En ligne].
http://www.microchipdirect.com/ProductSearch.aspx?Keywords=DM180021 Page
Microchip Co., 16-bit microcontroller, [En ligne].
http://ww1.microchip.com/downloads/en/devicedoc/39754B.pdf Page consultée
le 16 mars 2011
Microchip Co., PIC24FJ256DA210, [En ligne].
http://www.microchip.com/wwwproducts/Devices.aspx?dDocName=en547869 Page
BIBLIOGRAPHIE
66
[38] Mohamed N.Lokbani, Caractéristiques de base du langage Java, [En ligne].
http://www.iro.umontreal.ca/~lokbani/cours/ift1170/sessions/
administration/Cours/4Pages/Pdf/caracteristiques.pdf Page consultée le 14
mars 2011
[39] Muppet Labs, The Brainfuck Programming Language, [En ligne].
http://www.muppetlabs.com/~breadbox/bf/ page consultée le 15 mars 2011
[40] MySQL fr, MySQL : : La Base de Données Open Source la plus Populaire au Monde,
[En ligne]. http://www.mysql.fr Page consultée le 7 mars 2011
[41] Netissime 2011, Nom de domaine, hébergement, serveur dédié, Ecommerce,
référencement, emails professionnels : Netissime hébergeur français, [En ligne].
http://www.netissime.com Page consulté le 10 mars 2011
[42] onlybatteries.com, 14.8V 2600 mAh Li-Ion Battery Pack, [En ligne]. http:
//www.onlybatteries.com/showitem.asp?ItemID=15994.128&cat1=27&uid=2071
Page consulté le 12 mars 2011
[43] onlybatteries.com, 12 Volt 4500mAh (10 x 4/3 A) NiMH Battery Pack For 12V
Devices, [En ligne]. http:
//www.onlybatteries.com/showitem.asp?ItemID=16495.81&cat1=12&uid=1228
Page consulté le 14 mars 2011
[44] PostgreSQLFR, Partie V. Programmation serveur, [En ligne].
http://docs.postgresql.fr/9.0/server-programming.html Page consulté le 9
mars 2011
[45] Oracle, Oracle | Hardware and Software, Engineered to Work Together, [En ligne].
http://www.oracle.com, Page consultée le 6 mars 2011
[46] PEI GENESIS, Switch-mode charger NiCd/NiMH, [En ligne].
http://www.peigenesis.com/images/content/PEI_Power/BtPwr/nicd-nimh.pdf
Page consultée le 12 avril 2011
[47] PEI GENESIS, Switch-mode charger Li-Ion, [En ligne].
http://www.peigenesis.com/images/content/PEI_Power/BtPwr/lithium.pdf
[48] RFID University, Salon RFID Localisation sans fil : Le choix Zigbee, 2006, Mars,16
pages.
[49] SQLite, SQLite Home Page, [En ligne]. https://www.sqlite.org Page consultée le 9
mars
[50] Technologic Systemsm TS-7350 - Linux Computer with FPGA Expansion,[En ligne].
http://www.embeddedarm.com/products/board-detail.php?product=TS-7350#
[51] Texas Intruments, Intelligent Display Module - Summary, [En ligne].
http://focus.ti.com/lit/ug/spmu047/spmu047.pdf Page consultée le 12 Mars 2011
BIBLIOGRAPHIE
67
[52] Texas Intruments, Intelligent Display Module, [En ligne].
http://focus.ti.com/lit/ds/spms035f/spms035f.pdf Page consultée le 12 Mars
2011
[53] TigerDirect, Buy the CybertronPC XVA9080 Imperium Tower Server at TigerDirect.ca,
[En ligne]. http://www.tigerdirect.ca/applications/SearchTools/itemdetails.asp?EdpNo=5353317&Sku=C122-05500 Page consultée le 12 mars
[54] Tony Galmiche, Test de HSQLDB et Comparatif avec Sqlite, [En ligne].
http://fr.openoffice.org/Documentation/How-to/Bdd/09HSQLDB_OOo_0.5.pdf
Page consultée le 9 mars
[55] Transcend Inc, IDE SSD 1.0, [En ligne].
http://ec.transcendusa.com/product/ItemDetail.asp?ItemID=TS4GSSD10-M
Page consultée le 15 Mars 2011
[56] Tutorials Web, WiMAX - A Tutorial, [En ligne].
http://www.tutorialsweb.com/wimax/wimax.htm
[57] Vishay, Plasma Panel Display Modules, [En ligne].
http://www.vishay.com/docs/37086/128g064e.pdf Page consultée le 13 mars 2011
[58] Wikipedia, Wi-Fi,[En ligne]. http://fr.wikipedia.org/wiki/Wi-Fi Page consultée
le 8 mars 2011
[59] Wikipedia, Carrier Sense Multiple Access with Collision Avoidance, [En ligne].
http://fr.wikipedia.org/wiki/CSMA/CA Page consultée le 8 mars 2011
[60] Wikipedia, Carrier Sense Multiple Acces with Collision Avoidance, [En ligne]
http://en.wikipedia.org/wiki/Carrier_sense_multiple_access_with_
collision_avoidance Page consultée le 8 mars 2011
[61] Wikipedia, Extensible Markup Language, [En ligne]
http://fr.wikipedia.org/wiki/Extensible_Markup_Language Page consultée le 10
mars 2011
[62] Wikipedia, IEEE 802.11, [En ligne]. http://fr.wikipedia.org/wiki/IEEE_802.11
Page consultée le 9 mars 2011
[63] Wikipedia, IEEE 802.11b, [En ligne]. http://fr.wikipedia.org/wiki/IEEE_802.11b
[64] Wikipedia, IEEE 802.11i, [En ligne]. http://fr.wikipedia.org/wiki/IEEE_802.11i
[65] Wikipedia, MySQL anglais, [En ligne]. http://en.wikipedia.org/wiki/MySQL Page
[66] Wikipedia, MySQL français, [En ligne]. http://fr.wikipedia.org/wiki/MySQL Page
[67] Wikipedia, Oracle Database english, [En ligne].
http://en.wikipedia.org/wiki/Oracle_Database Page consultée le 10 mars 2011
BIBLIOGRAPHIE
68
[68] Wikipedia, Oracle Database français, [En ligne].
http://fr.wikipedia.org/wiki/Oracle_Database Page consultée le 10 mars 2011
[69] Wikipedia, PostgreSQL français, [En ligne].
http://en.wikipedia.org/wiki/PostgreSQL Page consultée le 9 mars 2011
[70] Wikipedia, PostgreSQL anglais, [En ligne].
http://fr.wikipedia.org/wiki/PostgreSQL Page consultée le 9 mars 2011
[71] Wikipedia, Remote Authentification Dial-In User Device, [En ligne].
http://fr.wikipedia.org/wiki/Remote_Authentication_Dial-In_User_Service
[72] Wikipedia, Réseau privé virtuel,[En ligne].
http://fr.wikipedia.org/wiki/R%C3%A9seau_priv%C3%A9_virtuel Page consultée
le 9 mars 2011
[73] Wikipedia, SQLite,[En ligne]. http://fr.wikipedia.org/wiki/SQLite Page
[74] Wikipedia, Wi-Fi Protected Access,[En ligne].
http://fr.wikipedia.org/wiki/Wi-Fi_Protected_Access Page consultée le 9 mars
2011
[75] Wikipedia, Wired Equivalent Privacy, [En ligne].
http://fr.wikipedia.org/wiki/Wired_Equivalent_Privacy Page consultée le 9
mars 2011
[76] Wikipedia, WiMAX,[En ligne]. http://fr.wikipedia.org/wiki/WiMAX Page
[77] Wikipedia, IEEE 802.16e,[En ligne]. http://fr.wikipedia.org/wiki/IEEE_802.16e
[78] Wikipedia, IEEE 802.16f,[En ligne]. http://fr.wikipedia.org/wiki/IEEE_802.16f
[79] Wikipedia, IEEE 802.16m,[En ligne]. http://fr.wikipedia.org/wiki/IEEE_802.16m
[80] Wikipedia, ZigBee,[En ligne]. http://fr.wikipedia.org/wiki/ZigBee Page
[81] Wikipedia, Téléphonie mobie,[En ligne].
http://fr.wikipedia.org/wiki/T%C3%A9l%C3%A9phonie_mobile Page consultée le
15 mars 2011
[82] Wikipedia, Rechargeable alkaline battery,[En ligne].
http://en.wikipedia.org/wiki/Rechargeable_alkaline_battery Page consultée
le 15 mars 2011
[83] Wikipedia, Accumulateur nickel-hydrure métallique, [En ligne].
http://fr.wikipedia.org/wiki/Accumulateur_nickelhydrure_m%C3%A9tallique#Points_forts_du_NiMH Page consultée le 14 mars 2011
BIBLIOGRAPHIE
69
[84] Wikipedia, Lithium-Ion batterie, [En ligne].
http://fr.wikipedia.org/wiki/Lithium-ion Page consultée le 15 mars 2011
[85] Wikipedia, Écran à cristaux liquides, [En ligne]. http:
//fr.wikipedia.org/wiki/%C3%89cran_%C3%A0_cristaux_liquides#TN.2C_DSTN
[86] Wikipedia, Passive Matrix Adressing, [En ligne].
http://en.wikipedia.org/wiki/Passive_matrix_addressing Page consultée le 13
mars 2011
[87] Wikipedia, Plasma Display, [En ligne].
http://en.wikipedia.org/wiki/Plasma_display Page consultée le 13 mars 2011
[88] Wikipedia, Diode électroluminescente organique, [En ligne].
http://fr.wikipedia.org/wiki/Diode_%C3%A9lectroluminescente_organique
[89] Wikipedia, Interface en ligne de commande,[En ligne].
http://fr.wikipedia.org/wiki/Interface_en_ligne_de_commande page consultée
le 15 avril 2011
[90] Wikipedia, User interface,[En ligne].
http://en.wikipedia.org/wiki/Web_interface page consultée le 15 avril 2011
[91] Wikipedia, Graphical user interface elements,[En ligne].
http://en.wikipedia.org/wiki/Elements_of_graphical_user_interfaces page
consultée le 15 avril 2011
[92] Wikipedia, Graphical user interface,[En ligne].
http://en.wikipedia.org/wiki/Graphical_user_interface page consultée le 15
avril 2011
[93] Wikipedia, Java (langage), [En ligne].
http://fr.wikipedia.org/wiki/Java_(langage)#Aper.C3.A7u Page consultée le 14
mars 2011
[94] Wikipedia, Python (langage), [En ligne].
http://fr.wikipedia.org/wiki/Python_(langage)#Caract.C3.A9ristiques Page
[95] Wikipedia, Solid-State drive,[En ligne].
http://fr.wikipedia.org/wiki/Solid-state_drive Page consulté le 15 mars 2011
[96] Wikipedia, Carte mémoire,[En ligne].
http://fr.wikipedia.org/wiki/Carte_m%C3%A9moire page consultée le 15 mars
2011
[97] Wikipedia, Disque dur,[En ligne]. http://fr.wikipedia.org/wiki/Disque_dur page
[98] William Hoskins, The 4.4BSD Copyright,[En ligne].
http://www.freebsd.org/copyright/license.html Page consultée le 8 mars
BIBLIOGRAPHIE
70
[99] W.W. Grainger.Inc, ENVIROCELL Rechargeable Battery, Type AA, PK 8, [En ligne].
http://www.grainger.com/Grainger/ENVIROCELL-Rechargeable-Battery3PET9?Pid=search page consultée le 15 mars 2011
Annexe A
Liste des sigles et des acronymes
A/N
ACK
ANSI
BSD
CSMA/CA
CTS
ECC
GSM
HSDPA
I2C
IEEE
IMEI
LCD
LED
Li-Ion
MTBF
Ni-MH
OLED
OS
PIC
RADIUS
RAM
RS232
RTS
SATA
SGBD
SGBDR
SGBDRO
SPI
Convertisseur Analogique à numérique
ACKnowledgement
American National Standards Institute
Berkeley software distribution license
Carrier Sense Multiple Access with Collision Avoidance
Clear To Send
Error Code Corrector
Global System for Mobile Communications
High Speed Downlink Packet Access
Inter Integrated Circuit
Institute of Electrical and Electronics Engineers
International Mobile Equipement Identity
Liquid Crystal Display
Light-Emitting Diode
Batterie Lithium - Ion
Mean Time Between Failure
Batterie Nickel - Hydrure métallique
Organic Light-Emitting Diode
Operating System
Peripheral Interface Controller
Remote Authentication Dial-In User Service
Random Access Memory
Norme standard de bus de communication série
Ready To Send
Serial Advanced Technology Attachment
Système de Gestion de Base de Données
Système de Gestion de Base de Données Relationnelles
Système de Gestion de Base de Données Relationnelles et Objet
Serial Peripheral Interface
71
ANNEXE A. LISTE DES SIGLES ET DES ACRONYMES
SQL
SSD
UART
USB
VPN
WEP
XML
Structured Query Language
Solid State Drive
Universal Asynchronous Receiver Transmitter
Universal Serial Bus
Virtual Private Network
Wired Equivalent Privacy
72

Oxypod - Université Laval

Transcription

Documents pareils

MÉDIAGRAPHIE 1. Ouvrage de référence CANADA, INDUSTRIE ET

Travail de retenue Utilisation du téléphone portable

Questionnaire - Lycée Louis Lachenal

Un Technicien

Fiche 1 Jules vient d`avoir 15 ans. Pour son anniversaire, ses

arabox - Aratice

solutions sun2go - The meeco Group

PROCESSEUR INTEL CORE i7 5600U : CARTE GRAPHIQUE

Batterie externe pour pc portableBATT/24000

EGF 01820