CNRS ECOTRON Cahier Des Charges Specs V5 PDF

CNRS ECOTRON UPS3248
1 Chemin du Rioux - Campus International de Baillarguet

34980 MONTFERRIER SUR LEZ
Tél : 04 67 91 37 02 E-mail : prénom.nom@ecotron.cnrs.fr
Olivier RAVEL – Marc DEFOSSEZ – Hélène LEMOINE
Cahier des charges pour la mise en place d’une

plateforme web de gestion et de partage des données
d’expérimentation
Page 1 sur 62 Date : 8 août 2012

TABLE DES MATIERES
TABLE DES MATIERES ................................................................................................................................................. 2
TABLE DES FIGURES .................................................................................................................................................... 3
TABLE DES MAQUETTES .............................................................................................................................................. 4
1 PRESENTATION DU CAHIER DES CHARGES .......................................................................................................... 5
1.1 Contexte ............................................................................................................................................................ 5
1.2 Contenu du DOCUMENT ................................................................................................................................... 5
1.3 Schémas UML utilisés........................................................................................................................................ 6
1.4 Termes utilisés .................................................................................................................................................. 7
2 CONTEXTE, ACTEURS ET PROCESSUS METIERS ................................................................................................... 8
2.1 Contexte et acteurs ........................................................................................................................................... 8
2.2 Les Processus métiers de la plateforme Ecotron ............................................................................................ 11
3 MODELISATION DES BESOINS FONCTIONNELS DE L’ECOTRON ..........................................................................17
3.1 Activité 0 : Soumission des projets.................................................................................................................. 17
3.2 Activité 1 : description des capacités de la plateforme Ecotron ..................................................................... 18
3.2.1 Identification des acteurs et des cas d’utilisation ....................................................................................... 18
3.2.2 Analyse de l’UC 1.1 : « décrire les capacités des plateaux » ....................................................................... 19
3.2.3 Analyse de l’UC 1.2 : « Regrouper et qualifier les capteurs » ..................................................................... 22
3.2.4 Analyse de l’UC 1.3 : « Décrire les ressources du laboratoire ».................................................................. 24
3.2.5 Analyse de l’UC 1.4 : « Décrire les services apportés par le système » ...................................................... 24
3.3 Activité 2 : Conception de l’expérimentation ................................................................................................. 25
3.3.2 Analyse de l’UC 2.1 : « Créer le projet et envoyer les accès » .................................................................... 26
3.3.3 Analyse de l’UC 2.2 : « Spécifier l’expérimentation» .................................................................................. 27
3.3.4 Analyse de l’UC 2.3 : « Validation des spécifications » ............................................................................... 30
3.3.5 Analyse de l’UC 2.4 : « Valider l’expérimentation» .................................................................................... 32
3.4 Activité 3 : Préparation de l’expérimentation ................................................................................................. 33
3.4.2 Analyse de l’UC 3.1 : « Gérer les tâches » ................................................................................................... 35
3.4.3 Analyse de l’UC 3.2 : « Réaliser les tâches » ............................................................................................... 38

3.4.4 Analyse de l’UC 3.3 : « Définir les critères qualité et les modèles de reconstruction» .............................. 39
3.5 Activité 4 : Suivi de l’expérimentatioN ............................................................................................................ 40
3.5.2 Analyse des UC 4.1 et 4.2 : « Gérer les incidents » et « Résoudre les incidents » ...................................... 41
3.5.3 Analyse de l’UC 4.3 : « Publier les données reconstruites » ....................................................................... 43
3.6 Activité 5 : Gestion des interventions et des résultats d’analyse ................................................................... 45
3.6.2 Analyse de l’UC 5.1 : « Demander des interventions » ............................................................................... 46
3.6.3 Analyse de l’UC 5.2 : « Gérer les demandes d’interventions » ................................................................... 47
3.6.4 Analyse de l’UC 5.3 et 5.4 : « Réaliser une intervention » et « Enregistrer des résultats d’analyse » ........ 49
3.7 Activité 6 : Consultation des données et gestion des post-traitements ......................................................... 51
3.7.2 Analyse des UC 6.1 et 6.2 : « Consulter et visualiser les données » et « Télécharger les données » ......... 53
3.7.3 Analyse de l’UC 6.3 et 6.4: « Traiter les données » et « Gérer les post-traitements » ............................... 54
3.8 Activité 7 : Constitution d’une base de connaissances ................................................................................... 55
3.8.2 Analyse des UC de l’activité 7 ..................................................................................................................... 56
4 ETUDE DES RESSOURCES INFRASTRUCTURELLES INFORMATIQUES DE L’ECOTRON ...........................................58
4.1 Inventaire des ressources existantes .............................................................................................................. 58
4.2 Inventaire des contraintes relevées ................................................................................................................ 61
ANNEXE 1 : PROCESSUS METIER GLOBAL (HORS ACTIVITE 5) .....................................................................................62
TABLE DES FIGURES
Figure 1: Diagramme de contexte : acteurs et flux de données ....................................................................................... 10
Figure 2: Diagramme d'acteurs ......................................................................................................................................... 10
Figure 3: Processus métiers – activités 0,1 & 2 « Soumission des projets », « Description des capacités de la plateforme
Ecotron » et « Conception de l’expérimentation » .......................................................................................................... 12
Figure 4: Processus métiers - activité 3 « Préparation de l’expérimentation » ................................................................ 13
Figure 5: Processus métiers - activités 4 « Suivi de l’expérimentation » .......................................................................... 14
Figure 6: Processus métiers - Activité 5 « Gestion des interventions et des résultats d'analyse » .................................. 15

Figure 7: Processus métiers - activités 6 & 7 « Consultation des données et gestion des post-traitements »,
« Constitution d’une base de connaissances » ................................................................................................................. 16
Figure 8: Cas d'utilisation de l'activité 0 : « Soumission des projets ».............................................................................. 17
Figure 9: Cas d'utilisation de l’activité 1 : « Description des capacités des plateaux » .................................................... 19
Figure 10: DSS de l'UC 1.1 « Décrire les capacités des plateaux » .................................................................................... 21
Figure 11: DSS de l'UC 1.2 « Regrouper et qualifier les capteurs » ................................................................................. 23
Figure 12: cas d'utilisation de l'activité 2 : « Conception de l’expérimentation » ............................................................ 26
Figure 13: DSS de l'UC 2.2 « Spécifier l’expérimentation » .............................................................................................. 29
Figure 14: DSS de l'UC 2.3 « Gérer les spécifications du projet » ..................................................................................... 32
Figure 15: Cas d'utilisation de l'activité 3 « Préparation de l'expérimentation » ............................................................. 34
Figure 16: DSS de l'UC 3.1 « Gérer les tâches » ................................................................................................................ 37
Figure 17: cas d'utilisation de l'activité 4 « Suivi de l’expérimentation » ......................................................................... 41
Figure 18: Cas d'utilisation de l'activité 5: « gestion des interventions et des résultats d’analyse » ............................... 46
Figure 19: Cas d'utilisation de l'activité 6 « Consultation des données et gestion des post-traitements » ..................... 52
Figure 20: Cas d'utilisation activité 7: « Constitution d’une base de connaissances » ..................................................... 55
Figure 23: Schéma global d'infrastructure du SI de l'Ecotron ........................................................................................... 59
Figure 24: Schéma compact de flux de données .............................................................................................................. 60
Figure 25: Schéma éclaté de flux de données (vue de l'existant) ..................................................................................... 60
Figure 28: Processus métier global (hors activité 5) ......................................................................................................... 62
TABLE DES MAQUETTES
Maquette 1: Le « configurateur » permet de spécifier une expérimentation ................................................................. 27
Maquette 2: Avancement de la préparation de l'expérimentation.................................................................................. 36
Maquette 3: liste des tâches organisées par catégories .................................................................................................. 38
Maquette 4: Consultation d'une publication de données secondaires ............................................................................ 44
Maquette 5: Fiche descriptive d'une intervention ........................................................................................................... 48
Maquette 6: Intervention et rattachement des résultats d'analyse ................................................................................ 50
Maquette 7: Construction d'une fenêtre d'étude (consultation des données) ................................................................ 53
Maquette 8: Edition d’une page type wiki ....................................................................................................................... 56
Maquette 9: Consultation d'une page type wiki .............................................................................................................. 57

1 PRESENTATION DU CAHIER DES CHARGES
1.1 CONTEXTE
Ce cahier des charges présente les spécifications systèmes, logicielles et matérielles dans le cadre de la mise en
place d’une application web de gestion et de partage des données d’expérimentation.
L’Ecotron est une plateforme du CNRS, UPS 3248, dédiée à l’écologie. Grâce notamment à ses trois plateaux, elle met
à disposition de la communauté scientifique, des infrastructures capables de simuler une grande variété de climats,
dont des climats du futur.
Les trois plateaux permettent de réaliser des expérimentations à différentes échelles intermédiaires entre le
laboratoire et l’in situ, afin d’étudier les réponses des écosystèmes face à des changements de l’environnement par
exemple. Les plateaux sont les suivants :
 Plateau macrocosme : 12 dômes pouvant accueillir des écosystèmes de plusieurs tonnes,

 Plateau mésocosme : 24 dômes pouvant accueillir des écosystèmes de quelques centaines de kilogrammes,
 Plateau microcosme : pouvant contenir un nombre variable d’écosystèmes de l’ordre du kilogramme.
Des paramètres fondamentaux comme la température, les conditions hydriques et le CO2 sont ainsi complètement
maitrisés et donnent accès aux modélisations les plus ambitieuses dans l’étude du réchauffement climatique.
La complexité de ces études réside dans l’acquisition et la gestion de données issues de plusieurs centaines de
capteurs disposés dans les différents plateaux. Chaque expérimentation impose une surveillance de plusieurs
centaines de paramètres biologiques mais aussi techniques (supervision du fonctionnement des groupes chaud/froid
par exemple). De plus, les expérimentations peuvent s’étaler dans le temps et durer jusqu’à 3 ans.
Grâce aux compétences internes à l’ECOTRON, l’acquisition des données n’est pas un problème et génère comme
convenu une quantité de données très importante. Néanmoins, la gestion de l’information demeure un point critique
pour parvenir à exploiter au maximum les données et faciliter leurs interprétations. Ce cahier des charges s'inscrit
dans ce cadre, afin de fournir aux utilisateurs une plateforme leur permettant d'échanger des données, ainsi qu'un jeu
d'outils statistiques pour l'interprétation scientifique.
1.2 CONTENU DU DOCUMENT
Le présent document synthétise les besoins de l’ECOTRON concernant la mise en place d’un système de partage des
données d’expérimentations et de gestion de projet. Ce document se structure en 4 grandes parties.
La démarche générale consiste à mettre en évidence l’ensemble des concepts clés nous permettant d’arriver à une
modélisation complète des spécifications du système. La suite du document est donc divisée en 4 chapitres que voici :
1. Description du contexte, identification des flux de données échangés entre les acteurs et le système et
description du processus métier global,
2. Modélisation des activités mises en évidence dans les processus métiers. Pour chaque activité :
a. Identification des cas d’utilisation,
b. Identification des acteurs impliqués,
c. Modélisation du ou des scénarii optimaux mettant en jeux les cas d’utilisation
d. Regroupement des cas d’utilisation en packages fonctionnels
3. Synthèse des ressources, contraintes hardwares
4. préconisations et dimensionnement
a. Description de l’architecture logicielle
b. Description architecture technique

1.3 SCHEMAS UML UTILISES
Les processus, les interactions avec les acteurs, les cas d’utilisation seront représentés par plusieurs diagrammes UML.
Chaque diagramme UML apporte une partie de la compréhension. Les diagrammes utilisés dans ce rapport sont les
suivants :
 Diagramme de contexte : permet de mettre en évidence les interactions (flux de données) entre les acteurs
et le système,
 Diagramme d’activité : permet de modéliser les processus métiers,
 Diagramme de cas d’utilisation (en anglais Use Case : UC) : permet de visualiser les actions que doit pouvoir
réaliser un acteur sur le système. Chaque cas a un début et une fin.
 Diagramme de séquence système (DSS) : permettant de visualiser l’enchainement des actions qu’il faut suivre
pour réaliser un UC.

1.4 TERMES UTILISES
Ce document réutilise des termes « métiers » de la plateforme ECOTRON. Chaque terme possède une définition
précise et particulière : Plateforme (Ecotron) : ce terme désigne l’ensemble des infrastructures de l’Ecotron.
 Plateau ou cosme : ce terme désigne un des 3 plateaux pouvant accueillir les expérimentations. Chaque
plateau possède des capteurs, à ce titre ils constituent des « sources » de données. Les plateaux disponibles
sur la plateforme Ecotron sont les suivants :
o Plateau macrocosme,
o Plateau mésocosme,
o Plateau microcosme.
Chaque plateau possède plusieurs enceintes.
 Enceinte : ce terme désigne la chambre ou le volume servant à étudier un écosystème/échantillon donné. Par
exemple, le plateau macrocosme possède 12 enceintes (les dômes) en extérieur recouvertes d’une bâche
transparente pouvant accueillir des échantillons de plusieurs mètres cubes.
 Emplacement : ce terme désigne l’emplacement d’un échantillon. Chaque enceinte possède un nombre
variable d’emplacements égal au nombre d’échantillons qu’elle peut accueillir.
 Echantillon : le terme d’échantillon est utilisé de manière générique pour désigner les blocs de terre étudiés
dans les enceintes.
 Laboratoire : ce terme désigne la partie de la plateforme Ecotron dédiée à la préparation des
expérimentations, au conditionnement et à l’analyse des échantillons prélevés sur les plateaux.
 Application web : ce terme désigne le futur logiciel dont l’interface sera disponible par le web, c'est-à-dire le
portail web.
Grâce aux définitions précédentes, il est possible de présenter synthétiquement comment les infrastructures de la
plateforme Ecotron sont imbriquées les unes par rapport aux autres :
 Plateforme Ecotron possédant :

o 3 plateaux possédant :
 Un nombre variable d’enceintes pouvant accueillir
 Un nombre variable d’emplacements pouvant accueillir
o Un seul échantillon (bloc de terre).
o 1 laboratoire

2 CONTEXTE, ACTEURS ET PROCESSUS METIERS
2.1 CONTEXTE ET ACTEURS
On identifie ici les différents acteurs et leurs interactions avec le système. Ces acteurs peuvent être humains ou
virtuels (comme des logiciels par exemple). Ci-après la liste des acteurs identifiés. Nous avons séparés les acteurs
humains des acteurs virtuels.
Acteurs humains :
 Directeur scientifique: il crée l’espace du projet et valide la mise en place de l’expérimentation une fois les
spécifications validées. Il doit pouvoir accéder à toutes les données de tous les projets.
 Directeur technique : il décrit les capacités des plateaux. Il valide la spécification du projet faite par un client.
Il met en place l’expérimentation et doit pouvoir suivre les données acquises en temps réel.
 Responsable plateau : Il est en charge du suivi de son plateau (selon les attributions du directeur technique).
Il doit pouvoir créer des tâches et les attribuer au personnel Ecotron.
 Personnel Ecotron: il doit accéder aux monitorings des expérimentations dans lesquelles il est impliqué. Il
doit pouvoir réaliser les tâches qui lui sont attribuées (par exemple installer un capteur). Cet acteur couvre la
diversité des compétences présentes dans l’Ecotron comme :
o Les experts en échange gazeux,
o Les automaticiens,
o Les prototypistes.
 Client: Il doit pouvoir se connecter à l’espace de son projet et spécifier son expérimentation. Une fois les
spécifications acceptées, il doit pouvoir suivre, exporter et retraiter les données d’acquisition.
 Responsable qualité des données : il doit décrire les critères de qualité utilisés pour l’expérimentation. Pour
ce faire il utilise le logiciel QCsettings. Il définit aussi au travers de ce logiciel les modèles utilisés pour la
reconstruction des données manquantes et lance leurs exécutions. Une fois ces traitements réalisés, il publie
les données pour les mettre à disposition du client.
 L’administrateur : il crée les utilisateurs et configure les connexions aux différentes bases de données. Nous
ne détaillerons pas dans cette étude le rôle « classique » de cet acteur. Nous le mentionnons ici pour ne pas
oublier qu’il doit faire partie du système.
Acteurs virtuels :
 Base de données GAM : cette base de données contient les fiches de vie des capteurs de la plateforme
(numéro de série, fabricant, coefficients de calibration, emplacement) et les enregistrements des mesures
effectuées par chaque capteur. Les capteurs sont reliés à des automates (national instrument). .
Les automates sont chargés d’enregistrer les mesures puis de les envoyer à la base de données propriétaire
« citadel »(NI). Chaque automate est identifié de manière unique dans Citadel.

Le directeur technique conserve dans GAM l’historique des relations capteur-automate en enregistrant cette
identification aussi appelée « variable ». C’est grâce à cette « variable » qu’il est possible de retrouver les
données d’un capteur par la suite.
Enfin, grâce à une routine d’export LabVIEW, les mesures sont copiées vers la base de données d’acquisition
qui est ensuite exploitée par QCsettings.
 Base des données expérimentales : cette base de données est alimentée par plusieurs sources de données.
On y retrouve ainsi 3 types de données :
o les données brutes, exportées par les routines LabVIEW depuis Citadel,
o les données « primaires », issues du retraitement des données brutes par le logiciel QCsetting et
selon les critères de qualité définis par le responsable qualité,
o les données « secondaires », issues de la reconstruction des données primaires par le logiciel
QCsettings et selon des modèles de reconstructions définis par le responsable qualité.
 Base de données critères de qualité : cette base de données contient l’ensemble des critères de qualité pour
la génération des données primaires. Cette base est générée par le responsable qualité des données avec le
logiciel QCsettings. Elle ne contient les informations que pour une seule expérimentation. Ceci implique qu’il
y ait une base de données par expérimentation.
Remarque : actuellement, elle ne contient pas les modèles de reconstruction utilisés pour la génération des
données secondaires, ces derniers étant directement implémentés dans QCsettings.
 QCsettings : il est le logiciel de retraitement et qualification des données brutes en données primaires et des
données primaires en données secondaires (reconstruites). Il est important de le mentionner dans ce
chapitre car il joue un rôle important dans le processus global de la plateforme Ecotron. Néanmoins, il ne
communique pas avec le système. Le système ne communique qu’avec sa base de données critères de
qualité.
Acteurs virtuels optionnels :
 Moteur de traitement statistique : Il est envisagé que le système puisse déléguer tout ou partie de ses
calculs statistiques à un processus indépendant afin de ne pas affecter ses performances.
 Source de données externe : Il est envisagé que le système puisse se connecter à des interfaces logicielles et
récupérer automatiquement des données suite à des requêtes préétablies par l’utilisateur. Les données ainsi
récupérées peuvent servir à des algorithmes optimisant les conditions climatiques des expérimentations
(utilisation de données de stations météorologiques).
Remarque : Il est aussi envisagé qu’à long terme, le système soit lui aussi une source de
données. Des interfaces Interface Machine Machine (IMM) seront à mettre en place, par
exemple des WebServices. Ce besoin n’étant pas prioritaire, il ne sera pas développé
dans la suite du rapport.
Le diagramme de contexte suivant (cf. Figure 1), présente les acteurs identifiés ci-dessus ainsi que les données qu’ils
échangent avec le système.

Contrôle et
traitements statistiques Utilisateurs, droits et paramétrage
Récupération des données Infos système

à traiter
Responsable qualité Administrateur

des données
Capteurs et variables <<acteur>>

Directeur scientifique
GAM
Validation des projets
Suivi scientifique des projets

<<acteur>>
Base des données
Capacités des plateaux, expérimentales
Management des expérimentations Données d’acquisition brutes, I et II
Système
Conception et suivi des
expérimentations
Critères de qualité et modèles
Directeur technique <<acteur>>
de reconstruction <<acteur>>
Base de données
QCsettings
critères de qualité
Création des tâches Données externes
Mise en place et Requêtes <<acteur>>

suivi des expérimentations en charge Données extenes
<<acteur>>
Responsable plateau Réalisation des tâches Données post-traitées
Logiciel de
Données d’acquistion + scripts
retraitement
Consultation des tâches
Ses capteurs
Résultats d’analyse
Suivi de son projet Convention:

Personnel Ecotron Export des données
Données envoyées vers le système au dessus de la flèche
Données envoyées par le système en dessous de la flèche

Client
Figure 1: Diagramme de contexte : acteurs et flux de données
Remarque concernant les acteurs humains :
D’un point de vue du système, les acteurs humains représentent un ensemble de droits donnés à un utilisateur. Un
utilisateur peut posséder plusieurs rôles et les rôles peuvent aussi s’imbriquer les uns dans les autres. On parle alors
d’héritage. Un acteur A hérite de l’acteur B, c'est-à-dire que l’acteur A possède en plus de ses droits les droits de
l’acteur B. En UML, ceci est représenté par une flèche allant de A vers B.
Le diagramme d’acteur ci-dessous (cf. Figure 2) représente les héritages entre acteurs pour notre contexte.
Directeur scientifique Directeur technique Responsable plateau Personnel Ecotron Client
Administrateur
Responsable qualité
des données
Figure 2: Diagramme d'acteurs

2.2 LES PROCESSUS METIERS DE LA PLATEFORME ECOTRON
Les échanges entre les acteurs et le système se réalisent au travers de plusieurs processus métiers que nous avons
modélisés dans les figures suivantes.
Les processus sont regroupés en « activité » afin de structurer l’analyse de ces derniers. Un code couleur est utilisé sur
les figures permettant d’identifier facilement chaque activité. Les éléments sans couleur représentent les processus
qui ne font pas partie du périmètre fonctionnel et qui ne seront pas informatisés.
Nous avons identifié 8 activités majeures nécessaires à la gestion et au partage des données d’une expérimentation :
0. Soumission des projets : (en gris sur la Figure 3),

1. Description des capacités de la plateforme Ecotron (en orange sur la Figure 3),
2. Conception de l’expérimentation (en jaune, cf. Figure 3),
3. Préparation de l’expérimentation (en vert, cf. Figure 4),
4. Suivi de l’expérimentation (en turquoise, cf. Figure 4),
5. Gestion des interventions et des résultats d’analyse (en bleu, cf. Figure 6),
6. Consultation des données et gestion des post-traitements (en violet, cf. Figure 7),
7. Constitution d’une base de connaissances (en rouge, cf. Figure 7).
Un schéma plus compact regroupant toutes les activités sauf l’activité 5 est disponible en annexe 1. Il permet d’avoir
une vision du processus dans sa globalité.

Client Directeur plateforme Directeur technique Responsable plateau
Activité 0: Soumission des projets Activité 1: Description des capacités de la

plateforme Ecotron
Cahier des
charges
Décrire les
capacités des
Soumettre un
Etudier le projet plateaux, du
projet
laboratoire et des
services du
système
Capacités
Accepter le
Demande de précisions
projet?
Non
Oui
Activité 2: Conception de l’expérimentation

Accès à la
plateforme Créer le projet
Se connecter
Spécifications
Spécifier le projet
Etudier les
spécifications
Première
Non
validation?
Deuxième
Non Oui
validaiton?
Oui
Il est possible de passer

l’activité de préparation de
l’expérimentation
Figure 3: Processus métiers – activités 0,1 & 2 « Soumission des projets », « Description des capacités de la plateforme Ecotron » et « Conception
de l’expérimentation »

Responsable plateau Personnel Ecotron Responsable qualité des données
Activité 3: Préparation de l’expérimentation
Préparer Mettre en place

l’expérimentation les critères qualité
Critères de
Tâches à qualité
réaliser
Mettre en place
les modèles de
Non reconstruction
Modèles de
Réaliser les
reconstruction
tâches
Tâches
validées?
Oui
Si toutes les tâches sont

validées, il est possible de
lancer l’expérimentation
Figure 4: Processus métiers - activité 3 « Préparation de l’expérimentation »

<<acteur>>
QCsettings
Client Responsable plateau Personnel Ecotron Responsable qualité

des données
Activité 4: Suivi de l’expérimentation
Données Brutes
Lancer Valider les

l’expérimentation données
Données
primaires
Modèle de
reconstruction
Consulter les Données

données cf. secondaires
Activité 6 reconstruites
Reconstruire les
données
Publier les
données
reconstruites
Déclarer des
incidents
Incidents
Résoudre les
incidents
Figure 5: Processus métiers - activités 4 « Suivi de l’expérimentation »

Client Directeur technique Responsable plateau Personnel Ecotron
Gestion des interventions et des résultats d’analyse
Réception et
Demander une
étude de la
intervention
demande
Intervention
Non
validée?
Oui
Réaliser Réaliser
l’intervention l’intervention
Observations et
résultats
d’analyse
Figure 6: Processus métiers - Activité 5 « Gestion des interventions et des résultats d'analyse »

Client Responsable qualité des données
Activité 6: Consultation des données et gestion des post-traitements
Mettre en place
Sélectionner les les post-
variables traitements
exécutables
Post-
traitemetns
Sélectionner le
post-traitement
Exporter les
données et/ou les
résultats
Fichiers de
données
Activité 7: Constitution d’une base de connaissances
Nouveaux
Consulter/Enrichir Scripts
la base de
connaissance
Télécharger les
scripts Scripts
Figure 7: Processus métiers - activités 6 & 7 « Consultation des données et gestion des post-traitements », « Constitution d’une base de
connaissances »

3 MODELISATION DES BESOINS FONCTIONNELS DE L’ECOTRON
3.1 ACTIVITE 0 : SOUMISSION DES PROJETS
Résumé :
Des clients potentiels (internaute non enregistré sur le portail WEB) doivent pouvoir consulter une partie de
l’application web. Cette partie publique doit pouvoir contenir :
 Un résumé des capacités des plateaux,

 Un lien vers le site internet de l’Ecotron, des adresses mails,
 Un formulaire de contact avec la possibilité d’attacher des fichiers pour soumettre un projet à l’Ecotron.
Le directeur scientifique doit recevoir des messages pour chaque soumission enregistrée sur le système. Il doit pouvoir
consulter toutes les soumissions de projets.
Un statut sur chaque soumission de projet doit permettre au directeur scientifique de valider ou d’invalider la
demande, ou de demander des précisions au soumissionnaire; il doit donc y avoir 3 statuts: "accepté", "refusé", ou "à
l'étude". Il faut aussi conserver l'historique des demandes.
Si la demande est acceptée, elle doit être rattachée au projet correspondant créé dans le système.
Acteurs impliqués dans cette activité :
 Le client non enregistré : il consulte la partie publique de l’application web

 Le directeur scientifique : il administre la partie publique et consulte les demandes.
Cas d’utilisation identifiés :
 UC 0.1 : Consulter la partie publique et soumettre un projet

 UC 0.2 : Administrer la partie publique,
 UC 0.3 : Gérer les soumissions de projet.
La figure suivante (Figure 8) présente les cas d’utilisation (dans les bulles) manipulés par les acteurs.
Activité 0: Soumission des projets
Administrer la
partie publique
Gérer les
>>
Directeur scientifique soumissions de projet

ue
pliq
im
<<
Consulter la partie
publique et soumettre un
projet
Client
Figure 8: Cas d'utilisation de l'activité 0 : « Soumission des projets »

3.2 ACTIVITE 1 : DESCRIPTION DES CAPACITES DE LA PLATEFORME ECOTRON
3.2.1 IDENTIFICATION DES ACTEURS ET DES CAS D’UTILISATION
Résumé :
En amont de toute expérimentation, le directeur technique en collaboration avec le directeur scientifique, doit décrire
les capacités de la plateforme Ecotron. Les objectifs de cette phase sont multiples :
 présenter à un client potentiel les paramètres mesurables (température, hygrométrie de l’air, etc.) par les
différents plateaux macrocosme, mésocosme et microcosme,
 capturer et qualifier précisément les besoins du client afin d’évaluer le coût potentiel d’une expérimentation
par exemple,
 pouvoir planifier la mise en production des capteurs en fonction des paramètres demandés par le client,
 et enfin présenter les services apportés par l’application web en termes de gestion de projet par exemple.
Afin de réussir à structurer la présentation de ces moyens disponibles, le responsable technique doit pouvoir
informatiser les éléments suivants :
 les plateaux macrocosme, mésocosme et microcosme et méso (disponible bientôt), en décrivant :

o les enceintes ou dômes associés,
o les capacités d’accueil des enceintes : nombre d’échantillons (blocs de terre) que l’enceinte peut
contenir,
o les capteurs associés à chaque enceinte,
 les paramètres mesurables par les capteurs,
 les ressources disponibles sur la plateforme Ecotron :
o le laboratoire,
o les instruments d’analyse,
 les services offerts par l’application web (le système).
1. le directeur technique: il informatise les différents éléments de la plateforme Ecotron,

2. le directeur scientifique : il doit pouvoir réaliser les mêmes actions que le directeur technique,
3. le responsable plateau : il doit assurer le fonctionnement de son plateau (informatique, mécanique,
instrumentation, logistique),
4. la base de données GAM : cette base de données contient la liste de tous les capteurs utilisés sur la
plateforme.
 UC 1.1 : Gérer et décrire les capacités des plateaux

 UC 1.2 : Regrouper et qualifier les capteurs
 UC 1.3 : Décrire les ressources du laboratoire
 UC 1.4 : Décrire les services apportés par le système
La figure suivante présente les cas d’utilisation (dans les bulles) manipulés par les acteurs. A noter la flèche du
directeur scientifique vers le directeur technique, signifiant que le premier hérite (possède) des capacités du second.

Activité 1: Description des capacités de la
plateforme Ecotron
<<acteur>>
Décrire les GAM
plateaux
<<impli
qu e>>
Regrouper et qualifier
les capteurs d'un plateau
Décrire les
ressources du laboratoire
Décrire les services
Directeur technique
apportés par le système
Responsable plateau
Figure 9: Cas d'utilisation de l’activité 1 : « Description des capacités des plateaux »
3.2.2 ANALYSE DE L’UC 1.1 : « DECRIRE LES CAPACITES DES PLATEAUX »
Acteur principal
Le directeur technique ou le directeur scientifique
Acteur secondaire
La base de données GAM
Objectifs
Le directeur technique doit pouvoir décrire les capacités des 3 plateaux. Il doit pouvoir aussi gérer l’évolution de ces
dernières. Actuellement, les plateaux se présentent comme ceci :
 Plateau macrocosme, composé de 12 cosmes (dômes) pouvant accueillir des échantillons de plusieurs
tonnes,
 Plateau mésocosme, composé de 24 cosmes pouvant accueillir des échantillons pouvant peser quelques
centaines de kilos,
 Plateau microcosme, composé d’un nombre variable de cosmes. Pour ce plateau, chaque cosme est une
enceinte climatique dans laquelle plusieurs échantillons de quelques kilos sont déposés.
La description des plateaux doit se faire facilement au travers de l’enchainement de plusieurs pages (comme un
wizard).
Préconditions
 Le directeur technique est authentifié,

 La base de données GAM est accessible.
Postconditions
Les capacités des plateaux sont connues.

Scénario nominal
1. Le directeur technique sélectionne ou crée un nouveau plateau,

2. Il crée ou modifie un cosme existant,
3. Il consulte la liste des capteurs provenant de GAM et fait une sélection de capteur,
4. Il associe cette sélection au cosme,
5. Il décrit le nombre d’échantillons que le cosme peut contenir,
6. Optionnellement, pour chaque emplacement d’échantillon, il associe un ou plusieurs capteurs provenant de
GAM.
Alternatives
3a et 6a le directeur technique souhaite consulter la liste des capteurs mais le système n’arrive pas à se connecter à
GAM :
1. Le système signale le disfonctionnement,

2. Le directeur technique peut réessayer la connexion,
3. Le directeur technique doit pouvoir continuer à créer des cosmes ou des emplacements vides de capteurs
(dans ce cas, il faut que le portail indique que la description des capacités est incomplète).
Exigences supplémentaires
Une organisation des capteurs est déjà disponible dans GAM (familles et sous-familles de capteurs). Le directeur
technique doit pouvoir retrouver cette organisation lorsqu’il parcourt la liste des capteurs et filtrer cette liste.
Diagramme de séquence système
Nous utilisons ici le schéma UML diagramme de séquence système (DSS) pour présenter le scénario optimal mettant
en évidence les interactions entre le système et les acteurs participants à cet UC.

Figure 10: DSS de l'UC 1.1 « Décrire les capacités des plateaux »

3.2.3 ANALYSE DE L’UC 1.2 : « REGROUPER ET QUALIFIER LES CAPTEURS »
Acteur principal
Le directeur technique ou le responsable plateau
Acteur secondaire
La base de données GAM
Objectifs
Pour chaque plateau, le directeur technique en collaboration avec le responsable du plateau correspondant, doit
pouvoir faire des groupes de capteurs quel que soit le cosme ou l’emplacement. Il souhaite ainsi regrouper les
capteurs ayant les mêmes caractéristiques et les mêmes gammes de mesures. Les groupes ainsi composés doivent
être présentés au client comme des paramètres mesurables. Ces paramètres mesurables constituent les capacités des
différents plateaux.
Le directeur technique doit aussi pouvoir créer des groupes de « monitoring » ne contenant que des capteurs de
gestion interne au laboratoire (comme le sas). Ces capteurs servent au bon déroulement des expérimentations, leurs
données peuvent être utilisées pour calculer les critères qualité, mais elles n'intéressent pas le client.
Préconditions
 Le directeur technique est authentifié,

 Il existe au moins un plateau entièrement décrit, cf. UC 1.1.
 La base GAM est accessible,
Postconditions
Les paramètres mesurables et de monitoring du plateau sont connus.
Scénario nominal
1. Sélection d’un plateau,

2. CRUD (CReate Update Delete) d’un groupe et description de celui-ci : public ou monitoring, gamme de
mesure, etc.,
3. Consultation de la liste de tous les capteurs regroupés par cosme et par emplacement,
4. Sélection de plusieurs capteurs, un ou plusieurs pour chaque cosme,
5. Enregistrement de cette sélection dans le groupe sélectionné.
Alternatives
3a Consultation de la liste des capteurs mais le système ne peut se connecter à GAM :
1. Le système signale le disfonctionnement

2. Le responsable technique peut réessayer la connexion
3. Le responsable technique doit pouvoir continuer à faire des groupes de capteurs mais les détails de ces
derniers contenus dans GAM ne sont pas disponibles (dans ce cas, il faut que le portail indique que la
qualification des capteurs est incomplète).
La création des groupes de capteurs doit se réaliser au travers d’une interface ergonomique permettant de visualiser
pour chaque cosme et chaque emplacement les capteurs associés.

<<Système>>
<<Acteur>>
Plateforme de
GAM
gestion
Directeur
technique
Sélectionner un plateau
CRUD un groupe
Visualiser les capteurs par cosme ou

par emplacement
Demander détails sur capteurs
Détails capteurs
Sélectionner une liste de capteur
Enregistrer la sélection
dans le groupe
Groupe créé/modifié
CRUD: CReate/Update/Delete
Figure 11: DSS de l'UC 1.2 « Regrouper et qualifier les capteurs »

3.2.4 ANALYSE DE L’UC 1.3 : « DECRIRE LES RESSOURCES DU LABORATOIRE »
Acteur principal
Le directeur technique
Objectifs
Le directeur technique doit pouvoir décrire les ressources ou services disponibles dans le laboratoire :
 Les locaux,
 Les instruments de mesures,
 D’autres services.
Ces ressources seront présentées aux clients pour qu’il puisse les réserver à tout moment ou lors d’une demande
d’intervention cf. paragraphe 3.6.2 : Analyse de l’UC 5.1 : « Demander des interventions ».
Le système doit ainsi gérer la disponibilité de chaque ressource dans un planning.
3.2.5 ANALYSE DE L’UC 1.4 : « DECRIRE LES SERVICES APPORTES PAR LE SYSTEME »
Acteur principal
Le directeur technique
Objectifs
Le directeur technique doit pouvoir administrer plusieurs pages dans l’application web permettant de décrire les
services apportés par le système comme :
 Les outils de gestion de projets,

 Le configurateur permettant de spécifier les expérimentations,
 Les outils de consultation des données.
Cette partie, consultable par le client, doit pouvoir aussi contenir de la documentation sur l’utilisation des
fonctionnalités du système.

3.3 ACTIVITE 2 : CONCEPTION DE L’EXPERIMENTATION
Résumé :
Un client doit pouvoir soumettre un projet à la plateforme Ecotron. Après étude du projet, le directeur scientifique
décide de créer un espace dédié à ce projet et donne les accès au client.
Grâce à la description des capacités des plateaux réalisée en amont par le directeur technique, le client, dans l’espace
dédié à son projet, doit pouvoir :
 Consulter les plateaux disponibles,

 Consulter la liste des paramètres mesurables de chaque plateau,
 Spécifier plus précisément son expérimentation en :
o Sélectionnant le plateau d’étude,
o En sélectionnant les paramètres qu’il veut mesurer,
o En décrivant son plan d’expérience (modalités, traitements, nombre d’échantillons, etc.).
Selon le plateau sélectionné, un responsable plateau est chargé d’étudier les spécifications de l’expérimentation.
Le responsable du plateau doit pouvoir modifier et ajuster les spécifications en fonction des possibilités du plateau.
Toutes les modifications doivent être tracées et des e-mails envoyés aux personnes impliquées dans le projet.
Le directeur scientifique valide obligatoirement les spécifications et autorise l’expérimentation avant sa mise en place.
Remarque : la demande initiale du projet n’est pas gérée dans le système car celle-ci se fait le plus souvent par des
échanges de mails directs. Elle n’est donc pas modélisée dans la suite du document.
1. Le client : il spécifie son expérimentation dans l’espace dédié à son projet,

2. Le responsable plateau : il modifie les spécifications en fonction des contraintes du plateau sélectionné,
3. Le directeur scientifique : il crée l’espace du projet et autorise l’expérimentation.
 UC 2.1 : Créer le projet et envoyer les accès,

 UC 2.2 : Spécifier l’expérimentation,
 UC 2.3 : Valider les spécifications,
 UC 2.4 : Autoriser l’expérimentation
Le schéma suivant représente les cas d’utilisation associés aux acteurs identifiés.

Activité 2: Conception de l’expérimentation
Créer le projet et
envoyer les accès
Autoriser
l'expérimentation
<<im
<<
im
p
liqu
pli
qu
e>>
e>
>
Responsable plateau
Valider les
spécifications
<<im
p lique
>>
Spécifier son
expérimentation
Client
Figure 12: cas d'utilisation de l'activité 2 : « Conception de l’expérimentation »
3.3.2 ANALYSE DE L’UC 2.1 : « CREER LE PROJET ET ENVOYER LES ACCES »
Acteur principal
Acteur secondaire
Le client
Objectif
Le directeur scientifique doit pouvoir créer des espaces aux projets qu’il juge pertinent. Les clients reçoivent ainsi leurs
accès et peuvent spécifier leurs expérimentations dans le système.
Exigences supplémentaires :
 A la création du projet le directeur scientifique doit pouvoir renseigner des informations sur le client (mails,
tel, etc.),
 Le directeur doit être capable de joindre des fichiers tels que le cahier des charges du client,
 Un wiki dédié à ce projet doit être automatiquement créé,
 Un mail automatique est envoyé au client avec les informations de connexion.

3.3.3 ANALYSE DE L’UC 2.2 : « SPECIFIER L’EXPERIMENTATION»
Acteur principal
Le client
Acteurs secondaires
 Le responsable plateau
 Le directeur scientifique
Objectifs
Afin de spécifier son expérimentation, le client accède au « configurateur » depuis l’espace dédié à son projet. Grâce à
une interface ergonomique, le client doit être guidé étape par étape dans la spécification de son expérimentation au
regard des capacités des plateaux décrites par le directeur technique.
L’interface du « configurateur » doit faire apparaitre l’avancement des spécifications en affichant les étapes
nécessaires à une spécification complète. La maquette ci-dessous (cf. Maquette 1) présente ce que pourrait être cette
interface.
4. Paramètres 6. Interventions 7. Laboratoire

1. Plateau 2. Plan d’expérience 3. Echantillons 5. Paramètres client
natifs
Témoin Ech 01 Ech 02 Ech 08

CO2 380 ppm
Vague de
chaleur et Ech 07 Ech 04
sécheresse
Modalités Entrer l’échantillon souhaité
Témoin
CO2 580 ppm
Vague de
chaleur et
sécheresse
Maquette 1: Le « configurateur » permet de spécifier une expérimentation
Préconditions
 Le client a reçu ses accès et est authentifié sur le système

 Les capacités des plateaux sont faites
Postconditions
L’expérimentation est entièrement spécifiée, prête à être validée.

Scénario nominal
1. Choix du plateau (macrocosme, mésocosme ou microcosme)

2. Définition du plan d’expérience (identification des conditions) :
a. Définition des modalités, par exemple 2 modalités de C02 : 380ppm et 520ppm,
b. Définition des traitements, par exemple 2 traitements : Témoin et Vague de chaleur et sécheresse
c. Définition du nombre de répétitions qui est fonction des possibilités du plateau choisi. Par exemple
pour le macrocosme il ne peut y avoir que 3 répétitions maximum.
3. Enregistrement, description des échantillons de l’expérimentation et répartition de ces derniers
aléatoirement ou manuellement dans les différentes modalités,
4. Le client sélectionne les paramètres mesurables qu’il veut suivre,
5. Le client indique s’il souhaite intégrer un ou plusieurs capteurs lui appartenant,
6. Le client indique si des interventions manuelles seront effectuées (mesures, traitements, etc.),
7. Enfin, le client demande la réservation de ressources ou services du laboratoire.
 Si le client ne sait pas répondre à certaines questions, le système doit lui proposer une aide en ligne avec des
exemples fictifs d’expérimentations,
 Le client doit pouvoir arrêter le processus de spécification et sauvegarder son travail en l’état,
 Si le client prévoit de faire des interventions, un agenda doit lui permettre de les planifier.
 A tout moment le client doit pouvoir exporter une synthèse des spécifications de son expérimentation
(export pdf par exemple).
Enfin concernant les capteurs du client, pour chacun il doit renseigner dans un formulaire les informations suivantes
(A voir) :
o nom capteur,
o fabricant,
o numéro série,
o gamme électrique,
o gamme physique,
o mécanique,
o droit d’auteur
o hygiène et sécurité
o Pièces jointes : certificat étalonnage.
Ce formulaire doit être une interface light de GAM. Quand le responsable plateau valide la mise en place des capteurs
client (cf. UC 2.3), le système doit alors inscrire automatiquement les capteurs clients dans GAM. L’implémentation de
ce mécanisme est à déterminer en fonction des contraintes. Il est envisageable :
 D’exporter une liste de capteurs de l’application web puis de l’importer dans GAM,
 De faire en sorte que l’application web puisse modifier la base de données GAM (de manière limitée et
sécurisée).

<<Système>>
Plateforme de
gestion
Client
{Capacités des
plateaux décrites}
Choix du plateau
Def Nb modalités
Def Nb traitements
Def Nb répétitions
Plan d’expérience créé
Loop Enregistrer et décrire 1
échantillon
Répartition des échantillons

dans les conditions
Option Répartition aléatoire
Sélection des paramètres

mesurables
Option Demande d’intégration de capteurs

Externes
Option Description des mesures

manuelles
Planification des interventions
Demande ressources/services
laboratoire
Spécification terminée,
Présentation d’une synthèse
Figure 13: DSS de l'UC 2.2 « Spécifier l’expérimentation »

3.3.4 ANALYSE DE L’UC 2.3 : « VALIDATION DES SPECIFICATIONS »
Acteur principal
Le responsable plateau
Acteur secondaire
Le client
Objectifs
Le responsable plateau doit être averti par un mail de toutes les mises à jour réalisées dans le configurateur.
Chaque étape dans le configurateur génère des spécifications. Il doit pouvoir commenter, modifier ou changer le
statut de ces dernières (passer de « nouveau » à « validé » ou « rejeté »).
Le système doit lui présenter les spécifications dans le configurateur ou sous forme d’une liste de demandes afin qu’il
soit facile de les consulter.
Le client doit être averti des mises à jour faites sur les spécifications par le responsable plateau et doit pouvoir
modifier les spécifications et/ou les commenter à son tour.
Le responsable plateau a validé l’expérimentation quand toutes les spécifications sont validées (statut à « validé »).
Préconditions
Le client a commencé à spécifier l’expérimentation grâce au configurateur.
Postconditions
Les spécifications sont validées.
Scénario nominal
1. Le responsable plateau consulte les spécifications,

2. Il sélectionne une spécification et peut consulter les détails de cette dernière
3. Il met à jour la spécification et un mail est envoyé au client. Les types de mises à jour possibles sont :
a. Commenter la spécification
b. Changer le statut de la spécification
c. Modifier le contenu de la spécification
Par ailleurs, si le client crée ou met à jour une de ses spécifications, le système envoie un mail au responsable plateau.
Alternatives
1a : la liste des spécifications est vide. Le responsable technique doit pouvoir créer les spécifications pour le client.
Le client ne doit pas pouvoir modifier une spécification si celle-ci a été « validée ». Néanmoins, il doit pouvoir la
commenter si besoin. S’il est utile de revenir sur une ou plusieurs spécifications, le responsable plateau doit pouvoir le
faire.

Si le responsable plateau consulte les spécifications sous forme d’une liste de demandes, celle-ci doit être organisée
par catégories afin d’améliorer la visibilité et identifier rapidement si aucune spécification n’a été faite pour une
catégorie en particulier. Les catégories sont basées sur les étapes du scénario de l’UC 2.2, à savoir :
 « Choix du plateau »,
 « Définition du plan d’expérience »,
 « Description des échantillons » (cette catégorie contiendra aussi la répartition de ces derniers),
 « Paramètres natifs » (issus de capteurs appartenant au plateau)
 « Paramètres client » (issus de capteurs appartenant au client),
 « Interventions»,
 « Laboratoire ».
Enfin, concernant les paramètres mesurables, le client doit pouvoir aussi préciser plusieurs choses :
 la gamme mesurable, c'est-à-dire les valeurs minimum et maximum envisagées,

 le taux d'échantillonnage, nombre de mesures par minute,
 les marqueurs,
 leur mode d'utilisation,
 etc.

<<Système>>
Plateforme de
gestion
Responsable Client
plateau
Créer ou mettre à
jour
Mail envoyé
une spécification
Consulter les spécifications
Sélectionner une spécification
Option Commenter une spécification

Mail envoyé
Option Changer le statut d’une

spécification Mail envoyé
Option Modifier une spécification

Mail envoyé
Figure 14: DSS de l'UC 2.3 « Gérer les spécifications du projet »
3.3.5 ANALYSE DE L’UC 2.4 : « VALIDER L’EXPERIMENTATION»
Ce cas d’utilisation simple mais essentiel est la matérialisation de l’engagement du laboratoire pour la réalisation du
projet soumis par le client. Le directeur scientifique possédant les mêmes droits que le responsable plateau peut
consulter les spécifications du projet. Si celles-ci sont suffisantes et validées par le responsable plateau, il valide alors
globalement les spécifications de l’expérimentation. Le système autorise donc le responsable plateau à passer à la
phase suivante de mise en place de l’expérimentation.

3.4 ACTIVITE 3 : PREPARATION DE L’EXPERIMENTATION
Résumé :
Grâce aux spécifications détaillées dans le système, le responsable plateau en déduit les tâches qu’il doit accomplir
avant le lancement de l’expérimentation. Les tâches dépendent de la nature des spécifications, par exemple :
 Selon le choix du plateau et du plan d’expérience :

o Si microcosme : Louer des chambres d’étude,
o Si mésocosme : Vérifier l’état des cosmes,
o Si macrocosme : Vérifier que les dômes sont en bon état,
o Réceptionner et mettre en place les échantillons
 Pour tous les « paramètres natifs » :
o Vérifier que le ou les capteurs sont disponibles et enregistrés dans GAM,
o Valider qu’ils fonctionnent par un étalonnage ou des tests,
o Attribuer une variable LabVIEW,
o Définir le critère de qualité de la variable (tâche déléguée au responsable qualité des données),
o Définir le modèle de reconstruction pour une variable (tâche déléguée au responsable qualité des
données),
 Pour les paramètres client :
o Installer le capteur,
o Valider le bon fonctionnement,
o Enregistrer le capteur dans GAM et lui attribuer une variable LabVIEW,
o Définir le critère de qualité de la variable (tâche déléguée au responsable qualité des données),
o Définir le modèle de reconstruction pour la variable (tâche déléguée au responsable qualité des
données),
 Pour les interventions manuelles :
o Valider le planning des interventions,
o Valider la disponibilité et le fonctionnement des instruments de mesures utilisés (par exemple des
balances, sondes, etc.),
 Pour les demandes concernant le laboratoire :
o Valider la disponibilité des ressources demandées,
o Préparer les services.
 Enfin, tout aussi important, des tâches sont dédiées à la validation du fonctionnement des capteurs/variables
de monitoring.
En résumé, pour l’ensemble des spécifications de l’expérimentation, le responsable plateau doit pouvoir créer/gérer
une liste de tâches lui permettant d’appréhender et de planifier le travail à faire avant le lancement véritable de
l’expérimentation. L’avancement du travail doit être facilement consultable.
L’association entre un capteur et une variable LabVIEW est contenue dans GAM. Le système doit récupérer
automatiquement cette information.
Le personnel Ecotron réalise les tâches qui lui sont attribuées.
Acteurs identifiés pour cette activité :
 Le responsable plateau : il gère les tâches à faire en relation avec les spécifications,
 Le personnel Ecotron: il réalise des tâches qui lui sont attribuées,

 Le responsable qualité des données : il met en place les critères de qualité et les modélisations pour les
paramètres natifs et clients (ceux avec une variable LabVIEW associée).
 La base de données GAM : elle contient le « mapping » entre les capteurs et les variables LabVIEW
 La base de données des critères de qualité : elle contient les critères de qualité.
 UC 3.1 : Gérer les tâches

 UC 3.2 : Réaliser les tâches
 UC 3.3 : Définir les critères de qualité et les modèles de reconstruction.
Activité 3: Préparation de
l’expérimentation <<acteur>>
GAM
Gérer les tâches

<<acteur>>
Base de données
Responsable Plateau
>> des critères de
ue qualités
iq
pl
i m
<<
Définir les critères de

Réaliser les tâches qualités et les modèles de
reconstruction
Personnel Ecotron
Responsable qualité
Figure 15: Cas d'utilisation de l'activité 3 « Préparation de l'expérimentation »

3.4.2 ANALYSE DE L’UC 3.1 : « GERER LES TACHES »
Acteur principal
Le responsable plateau
Acteur secondaire
La base de données GAM.
Objectifs
Le responsable plateau doit pouvoir créer plusieurs tâches en relation avec les spécifications. La description des tâches
est fonction de la catégorie de la spécification associée.
 Si catégorie « Plan d’expérience », la tâche est décrite avec :

o un champ référençant une enceinte
o une référence d’un échantillon
 « Paramètre natif » :
o une référence vers un capteur (vérification automatique dans GAM de l’attribution d’une variable),
o Une description de l’étalonnage (avec le coefficient de dérive)
o Une description du critère de qualité
o Une description du modèle de reconstruction
 « Paramètre client », mêmes informations que pour les « Paramètres natifs »,
 « Interventions manuelles » :
o une date de réalisation
o une ou plusieurs valeurs pour la ou les mesures/analyses réalisées par la suite.
 « Laboratoire »
o Une description permettant de référencer un local ou un instrument d’analyse.
Enfin quelle que soit la catégorie, les tâches contiennent les informations suivantes :
 La personne créatrice de la tâche,

 La date de création,
 La spécification associée,
 La personne à qui est attribuée la réalisation de la tâche,
 Un statut avec les valeurs suivantes « nouveau », « en cours », « réalisée » et « fermée »,
 Un délai souhaité.
Préconditions
 Connexion à la base de données GAM.

 Des utilisateurs de type personnel Ecotron sont enregistrés dans le système.
Postconditions
Une liste de tâches à réaliser avant de pouvoir démarrer l’expérimentation.
Scénario nominal
1. Le responsable plateau sélectionne une spécification

2. Il crée une tâche associée
3. Il décrit la tâche à l’aide des champs génériques
4. Il décrit la tâche plus précisément à l’aide des champs spécifiques

5. Il attribue la réalisation de la tâche à un membre du personnel de la plateforme
6. Il enregistre la tâche
7. Le système envoie un message à l’utilisateur concerné.
Alternatives
Pour les tâches associées à des paramètres, si la base de données GAM n’est pas accessible, le système le signale à
l’utilisateur, les vérifications automatiques ne sont pas faites.
La liste des tâches doit permettre au responsable plateau de voir l’avancement de la mise en place de
l’expérimentation (cf. Erreur ! Source du renvoi introuvable.). Cette liste correspond à une « check list » qu’il faut
bligatoirement valider avant de lancer véritablement l’expérimentation.
Maquette 2: Avancement de la préparation de l'expérimentation
Le responsable plateau doit pouvoir créer des tâches de type « Autre » afin de pouvoir créer n’importe quelle tâche
qui lui semblerait importante. [il pourrait aussi être utile d'attribuer une priorité, ou criticité, aux tâches; ex: 1)
critique, 2) nécessaire, 3) souhaitable, 4) facultative, 5) abandonnée]

<<Système>>
<<Acteur>>
Application web
GAM
Responsable Personnel
plateau Ecotron
Sélectionner une
spécification
Créer une
tâche
Décrire la tâche
Option Description plan

d’expérience
Option Description paramètres

natifs Récupération
variable
Variable
récupérée
Option Description paramètres

clients Récupération
variable
Variable
récupérée
Option Description intervention

manuelle
Attribution
réalisation
Tâche créée Mail
envoyé
Figure 16: DSS de l'UC 3.1 « Gérer les tâches »

3.4.3 ANALYSE DE L’UC 3.2 : « REALISER LES TACHES »
Pour ce cas d’utilisation simple, le personnel Ecotron doit recevoir des mails pour chaque tâche qui lui est attribuée.
Au travers d’une liste organisée par catégorie (cf Maquette 3), il consulte l’ensemble des tâches à réaliser.
Une fois le travail correspondant réalisé, il met à jour la tâche. Il doit pouvoir faire 3 actions :
 Commenter la tâche : par exemple décrire le travail réalisé,

 Changer le statut de la tâche : passer de « Nouveau » à « En cours » ou à « Réalisé »,
 Editer les champs spécifiques en fonction de la catégorie. Pour les tâches associées aux paramètres, il doit
pouvoir renseigner la variable LabVIEW.
Maquette 3: liste des tâches organisées par catégories

3.4.4 ANALYSE DE L’UC 3.3 : « DEFINIR LES CRITERES QUALITE ET LES MODELES DE
RECONSTRUCTION»
Acteur principal
Le responsable qualité des données
Objectifs
Le responsable qualité des données doit pouvoir indiquer au système où sont stockés les critères de qualité de
l’expérimentation.
Les critères de qualité sont définis dans une base de données gérée par le logiciel QCsettings. Chaque critère est
associé à une variable LabVIEW. Le système doit donc connaitre l’association paramètre/capteur/variable LabVIEW
afin de les récupérer automatiquement. Cette association est gérée dans les tâches de type « Paramètres natifs » et
« Paramètres client ».
Un critère de qualité est défini comme suit :
 Des valeurs seuils ou calculées :

o VALUE_MIN
o VALUE_MAX
o SLOPE_MAX
o STD_WIDTH
o STD_MIN
o STD_MAX
o GAP_MAX
 Optionnellement, en plus des valeurs précédentes, des calculs combinant d’autres variables.
Les modèles de reconstruction quant à eux sont directement implémentés dans le logiciel QCsettings. Ainsi, afin de les
référencer sur les paramètres natifs et client, le responsable qualité des données doit pouvoir les gérer dans un listing
dédié.
Préconditions
La base de données des critères de qualité est complète et disponible.
Postconditions
Le système est connecté à la base de données des critères de qualité de l’expérimentation. Les modèles de
reconstruction sont listés dans le système.
Le responsable qualité des données doit pouvoir consulter sous forme de liste tous les paramètres d’une
expérimentation avec les critères et les modèles récupérés. Il doit pouvoir exporter cette liste.

3.5 ACTIVITE 4 : SUIVI DE L’EXPERIMENTATION
Résumé :
L’expérimentation est maintenant lancée, l’acquisition des données est en cours et les données sont sauvegardées
dans la base des données expérimentales.
Le responsable plateau, le personnel du laboratoire ou le client doivent pouvoir consulter les données afin de vérifier
par exemple, que le déroulement de l’expérimentation se passe bien. La consultation des données est traitée plus en
détails dans l’activité 6 cf. paragraphe 3.7.
Il est important de préciser que le client n’a pas accès à toutes les données. A la différence du responsable plateau et
du personnel Ecotron qui ont accès :
 Aux données brutes,

 Aux variables de monitoring.
Si, en consultant les données, le responsable plateau constate une anomalie, il doit pouvoir déclarer un incident
contenant la description de l’anomalie. La résolution de l’incident peut être attribuée à un personnel Ecotron.
Enfin, le responsable qualité des données doit pouvoir publier les données secondaires. En effet, les données
secondaires ne sont pas générées au fil de l’eau (contrairement aux données brutes retraitées en continu et générant
les données primaires). Ainsi, ponctuellement, le responsable qualité des données réalise la reconstruction des
données. Il doit alors pouvoir notifier dans le système que des données secondaires sont disponibles à la consultation.
Un message est envoyé au client à chaque publication.
Acteurs intervenant dans cette activité :
 Responsable plateau: il consulte les données et gère les incidents,

 Personnel Ecotron: il consulte les données et résout les incidents
 Responsable qualité des données : il publie les données reconstruites (secondaires)
 La base des données expérimentales: elle contient les données d’acquisition, brutes, primaires et
secondaires
 UC 4.1 : Gérer les incidents

 UC 4.2 : Résoudre des incidents
 UC 4.3 : Publier les données reconstruites
 UC 4.4 : Consulter les données

Activité 4: Suivre l’expérimentation
Gérer les incidents

Responsable plateau
Publier les données
<< reconstruites
im
pli
qu
e>
> Responsable qualité
Résoudre les
incidents
Personnel Ectron
Consulter les
données cf. activité 6
Client
Figure 17: cas d'utilisation de l'activité 4 « Suivi de l’expérimentation »
3.5.2 ANALYSE DES UC 4.1 ET 4.2 : « GERER LES INCIDENTS » ET « RESOUDRE LES
INCIDENTS »
Acteur principal
Responsable plateau
Acteurs secondaire
Le personnel Ecotron
Objectifs
Au cours de l’expérimentation, le responsable plateau doit pouvoir gérer une liste d’incidents décrivant différentes
anomalies identifiées en consultant les données par exemple. Les incidents sont décrits de la manière :
 Une description,
 Une priorité,
 Un délai,
 Un personnel Ecotron pour résoudre l’incident,
 Un statut pouvant prendre les valeurs suivantes : « Nouveau », « En cours », « Résolu » et « Fermé ».
A la différence des tâches, les anomalies ne sont pas spécifiquement liées à un paramètre ou au plan d’expérience,
elles sont génériques.
Le personnel Ecotron doit être averti par mail des incidents qui lui sont attribués. Il doit pouvoir mettre à jour
l’incident :
 Commenter l’incident et décrire comment il a résolu l’incident,

 Passer le statut à « En cours » ou « Résolu ».
Seul le responsable plateau peut « fermer » les incidents une fois qu’ils sont « résolus ».
Préconditions
L’expérimentation est lancée.
Post conditions
Les incidents survenus lors de l’expérimentation sont tracés dans le système.
Scénario nominal
Le scénario nominal est représenté dans la figure suivante.
<<Système>>
Plateforme de gestion
Responsable Personnel
plateau Ecotron
Déclaration d’un incident

Message envoyé
Résolution de l’incident
Statut « Résolu »
Message envoyé
Fermeture de l’incident, statut

« Fermé »
Alternatives
Le responsable plateau doit pouvoir consulter la résolution de l’incident et convenir que celle-ci n’est pas suffisante. Il
repasse alors le statut de « Résolu » à « En cours » et motive son choix.
Les incidents sont listés et doivent être organisables par différents critères : priorité, délai, etc.

3.5.3 ANALYSE DE L’UC 4.3 : « PUBLIER LES DONNEES RECONSTRUITES »
Acteur principal
Responsable qualité des données
Acteurs secondaires
Responsable plateau et client.
Objectifs
Les données reconstruites sont les données « secondaires » générées par le logiciel QCsettings selon les modèles de
reconstruction définis par le responsable qualité des données. Cette action est exécutée environ tous les 2 jours sur
les données disponibles et encore non retraitées. Les données ainsi générées sont stockées dans la base des données
expérimentales (elles n’écrasent ni les données brutes ni les données primaires).
Cette reconstruction ne peut se faire au fil de l’eau car les modèles ont besoin d’un historique de quelques jours.
Afin de publier les données, le responsable qualité des données doit pouvoir indiquer dans le système :
 L’expérimentation concernée,
 La ou les variables concernées par la reconstruction,
 La période couverte par la reconstruction,
 Les tables dans la BD expérimentale où sont stockées les données.
Une fois la publication soumise, le système exécute des tests sur les données. Par exemple, il vérifie les identifications
des variables. Si des erreurs surviennent, le système doit les afficher dans l’interface et la publication est alors
annulée.
Si tout se passe bien, la publication est prise en compte, des messages aux personnes impliquées dans
l’expérimentation sont envoyés.
Préconditions
Des données reconstruites sont disponibles.
Post conditions
Les données reconstruites sont publiées.
Scénario nominal
1. Le responsable qualité des données sélectionne l’expérimentation concernée,

2. Il crée une publication,
3. Il consulte l’ensemble des variables concernées par une reconstruction,
4. Il sélectionne tout ou partie de ces variables,
5. Il décrit la publication : période couverte, commentaires, etc.,
6. Il indique où trouver les données dans la base expérimentale
7. Il soumet la publication
8. Le système vérifie les données :
a. Pas de problème, les données sont publiées et un mail est envoyé au client
b. Des problèmes sont identifiés et affichés dans l’interface.

Si des erreurs surviennent, la publication ne doit pas être effacée. Elle reste dans un état « non effective ». Le
responsable qualité des données peut ainsi régler les problèmes et la resoumettre.
Ci-dessous (cf. Maquette 4), une maquette présente ce que pourrait être la consultation d’une publication. A noter la
référence vers les données reconstruites.
Maquette 4: Consultation d'une publication de données secondaires

3.6 ACTIVITE 5 : GESTION DES INTERVENTIONS ET DES RESULTATS D’ANALYSE
Résumé :
Le client doit pouvoir faire des demandes d’intervention. Le plus souvent, les demandes sont faites lors de la phase de
conception de l’expérimentation, mais il doit être possible d’en faire aussi pendant l’expérimentation. Chaque
demande est étudiée, validée et planifiée par le directeur technique ou le responsable plateau.
Les interventions peuvent être de différentes sortes :
 prélèvements d’échantillons,
 traitements ou manipulations (ex : arrosage),
 mesures directes comme des pesées ou l’utilisation d’une sonde manuelle.
Les demandes validées et planifiées peuvent être réalisées par le client ou un membre du personnel Ecotron.
Dans le cas d’un prélèvement, l’échantillon peut être analysé dans le laboratoire d’Ecotron ou chez le client. Si le client
a besoin des services associés au laboratoire, il doit les décrire précisément suffisamment à l'avance afin que les
responsables puissent lui réserver les ressources (instruments d’analyse, locaux, etc.).
Le système doit permettre au client d’enregistrer le ou les résultats de l’analyse après coup.
 Le directeur technique : il valide les demandes et gère les interventions,

 Le responsable plateau : il doit pouvoir aussi valider des demandes,
 Le client : il demande des interventions, les fait réaliser ou les réalise lui-même et enregistre des résultats
d’analyse,
 Le personnel Ecotron: il doit pouvoir réaliser des interventions pour le compte du client.
 UC 5.1 : Demander des interventions,

 UC 5.2 : Gérer les demandes interventions,
 UC 5.3 : Réaliser une intervention,
 UC 5.4 : Enregistrer des résultats d’analyse.

Activité 5: Gestion des interventions et des
résultats d’analyse
Gérer les demandes

d’interventions
Client e>>
p liqu
<<im Directeur technique
Demander des interventions
Enregistrer des
Personnel Ecotron résultats d'analyse Responsable plateau
Réaliser une
intervetion
Figure 18: Cas d'utilisation de l'activité 5: « gestion des interventions et des résultats d’analyse »
3.6.2 ANALYSE DE L’UC 5.1 : « DEMANDER DES INTERVENTIONS »
Acteur principal
Le client
Objectifs
Le client doit pouvoir décrire les interventions qu’il souhaite réaliser au cours de son expérimentation (description,
date souhaitée, etc.).
Des champs spécifiques seront à sa disposition pour préciser s’il souhaite utiliser les services du laboratoire. Par
exemple, le système doit lui proposer une liste d’instruments d’analyse mis à disposition par l’Ecotron pour que le
client puisse les réserver.
Chaque intervention doit pouvoir être rattachée à l’une de ces 3 catégories pour en améliorer leur gestion :
 Catégorie « prélèvement »,
 Catégorie « traitement »,
 Catégorie « mesure directe ».
La liste des instruments d’analyse et des catégories doit pouvoir être administrable par le directeur technique.

Préconditions
 Le projet est au minimum dans la phase de conception.

 Les instruments de mesure sont enregistrés dans le système.
Post conditions
Demandes d’interventions gérées et tracées dans le système.
Scénario nominal
1. Demande d’intervention,
2. Description de la demande avec un délai souhaité,
3. Demande d’utilisation des ressources ou services du laboratoire :
a. Consultation de la liste des instruments d’analyse disponibles
b. Réservation du ou des instruments
c. Besoin d’un local : oui/non ?
d. Demande d’un service en particulier.
3.6.3 ANALYSE DE L’UC 5.2 : « GERER LES DEMANDES D’INTERVENTIONS »
Acteur principal
Le directeur technique ou le responsable plateau
Acteur secondaire
Le client
Objectifs
Si le projet est dans la phase de conception c’est le directeur technique qui reçoit les demandes d’intervention. A
partir du moment où le projet est dans l’étape de préparation, un responsable plateau a été désigné pour
l’expérimentation, c’est donc lui qui reçoit et gère les demandes d’intervention.
Gérer les demandes d’intervention signifie :
 Pouvoir visualiser toutes les demandes listées et triées par catégorie ou directement sur un calendrier. Les
demandes d’un même projet seront associées à un même agenda (même couleur),
 Valider les demandes faites par le client en vérifiant que les ressources demandées par le client sont
disponibles,
 Suivre l’état d’avancement des interventions. Savoir si elles sont réalisées ou en cours,
 Pouvoir les archiver quand elles ont été réalisées par le client ou un personnel Ecotron.
Préconditions
Des demandes ont été faites par le client.
Scénario nominal
1. Le directeur technique ou le responsable plateau consulte les demandes organisées par catégorie ou
présentées dans un calendrier,
2. Il sélectionne une demande et consulte les détails (cf. Maquette 5)
3. Après avoir pris connaissance de la demande, il choisit de faire l’une des actions suivantes :

a. Il valide la demande. Le système change le statut de la demande et la passe à « validée ».
b. La demande est incomplète ou impossible (ressources indisponibles), il commente la demande avec
un message signalant pourquoi il ne peut répondre favorablement à la demande. Un message est
envoyé au client pour le prévenir qu’une réponse l’attend,
c. Il archive la demande si celle-ci a été réalisée.
La fiche descriptive de l’intervention pourrait ressembler à la maquette ci-dessous (cf. Maquette 5).
Maquette 5: Fiche descriptive d'une intervention

3.6.4 ANALYSE DE L’UC 5.3 ET 5.4 : « REALISER UNE INTERVENTION » ET « ENREGISTRER DES
RESULTATS D’ANALYSE »
Acteur principal
Le client
Acteur secondaire
Un membre du personnel Ecotron
Objectifs
Une fois l’intervention programmée, le client ou le personnel Ecotron doit pouvoir réaliser la demande. Ceci consiste
à:
 Mettre un commentaire (optionnel),

 Changer le statut de l’intervention à « Réalisée »
 Ajouter un ou plusieurs résultats (optionnels).
Précondition
La demande a été étudiée et validée par le responsable plateau ou le directeur technique cf. UC 5.2
Postconditions
La demande a été mise à jour, elle est réalisée.
Scénario nominal
1. Consultation des demandes du projet,

2. Sélection d’une demande,
3. Mise à jour de la demande : il (le client ou le personnel Ecotron) peut changer le statut de la demande à
« Réalisée »
4. Enregistrement d’un ou plusieurs résultats avec les dates associées,
Alternative :
3a : la demande n’a pas été validée par un responsable, il ne peut que modifier sa demande ou ajouter un
commentaire.
Il faut mettre en place un système simple permettant de récupérer facilement les résultats contenus dans les
interventions. Pour ce faire, le client doit pouvoir maintenir une liste de « Paramètres personnels ».
Lors de la mise à jour d’une intervention, le client doit pouvoir choisir un paramètre dans cette liste et lui associer une
ou plusieurs valeurs résultat.
La maquette ci-dessous illustre l’enregistrement de résultats dans une intervention (cf. Maquette 6).

Maquette 6: Intervention et rattachement des résultats d'analyse

3.7 ACTIVITE 6 : CONSULTATION DES DONNEES ET GESTION DES POST-TRAITEMENTS
Préambule :
Au travers d’une interface spécifique, les utilisateurs au sens large doivent pouvoir accéder aux données en fonction
de leurs droits et attributions respectives. Par exemple :
 Le directeur scientifique et le directeur technique doivent pouvoir accéder à toutes les données
expérimentales de toutes les expérimentations,
 Le responsable plateau ne consulte que les données de son plateau,
 Le client ne consulte que les données expérimentales associées à ses paramètres, sans les variables dites de
« monitoring ».
Néanmoins quelles que soient les données, l’interface de consultation reste la même. Nous utiliserons ici le client
comme acteur par défaut dans ce chapitre.
Résumé :
Le client doit pouvoir, au travers d’une interface spécifique, consulter les données expérimentales. Une navigation
préétablie doit permettre au client de procéder en deux étapes.
Premièrement, paramétrage d’une fenêtre d’étude :
 Sélectionner une ou plusieurs enceintes (dôme ou chambre d’étude)

 Visualiser le listing des variables disponibles,
 Sélectionner une ou plusieurs variables
 Choisir une date de début et de fin,
 Sélectionner le pas de temps (par heure, par semaine, etc. => données moyennées).
Deuxièmement, une fois la sélection des données faites, le client doit pouvoir choisir entre différentes options :
 Visualiser sur un graphique paramétrable la ou les variables,

 Sélectionner un post-traitement « valide » pour la ou les variables sélectionnées, et voir les résultats du
calcul,
 Exporter les données, par exemple dans un fichier CSV ou un fichier compatible MatLab ou R.
Le responsable qualité des données gère les post-traitements disponibles.
 Le client : il se connecte à l’interface pour consulter, exporter et post-traiter des données.

 Le responsable qualité des données : il gère le listing des post-traitements disponibles.

 UC 6.1 : Consulter et visualiser les données,

 UC 6.2 : Télécharger les données,
 UC 6.3 : Traiter les données
 UC 6.4 : Gérer les post-traitements
Activité 6: Consultation des données et

gestion des post-traitements
Télécharger les
données
<<acteur>>
BD d’acquisition
Consulter et
visualiser les données
Client liq ue>>

<<imp
<<acteur>>
Optionnellement Logiciel de
Traiter les données
retraitement
<<implique>
>
Gérer les
Responsable qualité post-traitements
Figure 19: Cas d'utilisation de l'activité 6 « Consultation des données et gestion des post-traitements »

3.7.2 ANALYSE DES UC 6.1 ET 6.2 : « CONSULTER ET VISUALISER LES DONNEES » ET
« TELECHARGER LES DONNEES »
Acteur principal
Le client
Objectifs
Le client doit pouvoir consulter ses données expérimentales en configurant une fenêtre d’étude puis en choisissant de
les visualiser dans un tableau, sur un graphique paramétrable ou de les exporter.
L’interface doit être suffisamment ergonomique pour que le paramétrage de la fenêtre d’étude soit intuitif (cf.
Maquette 7).
Consultation des données

Plan d’expérience
Ech 01 Ech 02 Ech 08

Témoin
CO2 380 ppm
Vague de
chaleur et
sécheresse
Modalités
Sélectionner une enceinte
Témoin
CO2 580 ppm
Vague de
chaleur et
sécheresse
Sélectionner toutes les enceintes
Variables disponibles pour toutes les enceintes Période

Capteurs famille température
Date de début: 12/06/12 – 09:00
VAR_01 Date de fin: 12/06/12 – 17:00

VAR_02
VAR_03 Données moyennées par: heure
….. Sélectionner les variables Ctrl + clic
Post-traitements
Description du post-tratement
Dérivée
Lorem ipsum dolor sit amet, consectetur adipiscing elit.
Donec at eros in leo tincidunt venenatis ut at leo. Maecenas
Sur toutes les variables laoreet consequat sapien eget bibendum. Donec metus est,
Sur une variable vestibulum ac mollis et, tincidunt sed
VAR_01 Exécution: Synchrone
Sortie
Paramétrage graphique
Tableau Export Graphique
Echelle logarithmique
100 lignes par page CSV Double ordonnées
MatLab Type de graph BoxPlot
R
Maquette 7: Construction d'une fenêtre d'étude (consultation des données)
Préconditions
Le plan d’expérience et les variables de l’expérimentation sont connus du système.
Postconditions
Fenêtre d’étude paramétrée.

3.7.3 ANALYSE DE L’UC 6.3 ET 6.4: « TRAITER LES DONNEES » ET « GERER LES POST-
TRAITEMENTS »
Acteur principal
Le responsable qualité des données
Objectifs
Le client doit pouvoir choisir de traiter les données avec l’un des post-traitements disponibles.
Il est important de garder à l’esprit que les post-traitements peuvent prendre plus ou moins de temps de calcul en
fonction de la quantité de données sélectionnée et de la complexité des algorithmes.
Chaque post-traitement doit faire l’objet d’une étude de performance par le responsable qualité des données. Si un
post-traitement est qualifié de « trop gourmand » en ressource, alors il ne doit pas être exécuté dans la foulée (juste
après la définition de la fenêtre d’étude). La demande de post-traitement est alors stockée dans une file d’attente
gérée par le système qui les exécute de manière asynchrone quand les ressources sont disponibles (la nuit par
exemple).
Dès qu’un post-traitement est réalisé, le résultat associé est stocké et un message est envoyé au client pour le
prévenir.
Le responsable qualité des données doit pouvoir consulter la file d’attente des demandes de post-traitement, changer
l’ordonnancement ou encore annuler des demandes.
Enfin, certains post-traitements sont dédiés au monitoring et ne doivent pas être disponibles pour le client.
Pour qualifier correctement les post-traitements, le responsable qualité des données doit pouvoir :
 Décrire le fonctionnement et l’intérêt du post-traitement (disponible pour le client),

 Indiquer les contraintes : nombre de variables, type de variables (discrètes, flottantes, etc),
 Indiquer si l’exécution est synchrone ou asynchrone (cf. Maquette 7),
 Indiquer si le post-traitement est réservé au monitoring.
Avec les contraintes, le système doit pouvoir vérifier automatiquement s’il est possible d’effectuer le post-traitement.
Sinon, il indique au client pourquoi.
Enfin, si une ressource de calcul externe est disponible, le système doit lui déléguer tous les post-traitements
asynchrones.

3.8 ACTIVITE 7 : CONSTITUTION D’UNE BASE DE CONNAISSANCES
Résumé :
Le client doit pouvoir déposer et organiser lui-même ses notes et ses remarques dans un espace dédié à son projet. Il
doit aussi pouvoir y déposer des fichiers comme des scripts de retraitements des données.
Cet espace est aussi éditable par le responsable technique et les membres du personnel impliqués dans le projet du
client.
Enfin, cet espace est consultable librement par les autres clients afin que ces derniers puissent télécharger les scripts
et les exécuter chez eux sur les données de leurs expérimentations.
Remarque : le responsable qualité des données peut décider d’intégrer dans un post-traitement un script déposé par
un client si celui-ci est pertinent.
Acteur impliqué dans cette activité :
 Le client : il organise ses notes et dépose des fichiers dans son espace. Il peut aussi consulter les ressources
des autres clients.
 UC 7.1 : Ajouter et gérer ses ressources documentaires

 UC 7.2 : Déposer des scripts de retraitement
 UC 7.3 : Consulter toutes les ressources documentaires
Activité 7: Constitution d’une base de

connaissances
Déposer des scripts

Ajouter et gérer ses
ressources documentaires
Client Consulter toutes les

ressources documentaires
Figure 20: Cas d'utilisation activité 7: « Constitution d’une base de connaissances »

3.8.2 ANALYSE DES UC DE L’ACTIVITE 7
Acteur principal
Le client
Objectifs
L’ensemble des UC de cette activité sont couverts par des outils de type « wiki ». Les principales fonctionnalités de ce
type d’outil permettent au client de :
 Créer autant de pages qu’il le souhaite,

 Gérer la mise en page,
 Lier les pages entre elles (gestion de la navigation),
 Attacher des fichiers à chaque page (images, scripts).
Ci-après, deux maquettes présentent l’édition (cf. Maquette 8) et le rendu d’une page (cf. Maquette 9) de wiki
contenant des images et des scripts.
Maquette 8: Edition d’une page type wiki

Maquette 9: Consultation d'une page type wiki

4 ETUDE DES RESSOURCES INFRASTRUCTURELLES INFORMATIQUES DE L’ECOTRON
4.1 INVENTAIRE DES RESSOURCES EXISTANTES
Résumé :
Il est important de clarifier que les informations capturées dans cette section ne sont pas absolument exhaustives. En
effet, une étude hardware exhaustive dans le contexte de cette étude ne présenterait qu’un intérêt très marginal et
un lien peu pertinent avec le sujet. Ainsi, les éléments inventoriés ont été classés selon 5 thèmes :
 Interlocuteurs
 Réseau local
 Serveurs locaux
 Stockage local
 Ressources externes
Objectifs :
L’inventaire a pour objectif de comprendre et représenter l’organisation infrastructurelle du système d’information de

l’Ecotron afin d’en déduire, en fonction aussi des contraintes décrites précédemment, des préconisations.
Réseau :
Le réseau est composé des éléments suivants:
 Accès extérieur (Internet) : sDSL 2M symétrique

 Tête de réseau Orange Business Service / Juniper
 Routeur / Pare-feu FORTINET
 5 VLANs sont configurés dont 2 pour l'administration à usage exclusif de la DSI (direction des services
informatiques du CNRS)
o Réseau 10.3.x.x: réseau acquisition utilisé par les capteurs, les automates et donc pour la supervision
o Réseau 10.4.x.x: réseau bureautique (postes clients, serveurs et stockage)
o Réseau 10.5.x.x: réseau GUEST wi-fi
 Le réseau est configuré en IPv4 et est constitué physiquement de 4 switches Cisco (1x 1Gbps + 3x 100Mbps)
gérant les 5 VLANs
o swecotron1 (Cisco Catalyst 2960G):
 ports 01-20 sur VLAN 10.4 (postes et serveurs)
o swecotron2 (Cisco Catalyst 2960):
 ports 01-19 sur VLAN 10.4 (postes) SAUF 1 port sur VLAN 10.5 (borne d'accès Wi-Fi GUEST)
 ports 20-24 sur VLAN 10.3 (acquisition)
 Un projet destiné à faciliter l’identification des réseaux au niveau des baies de brassage est EN COURS. Il
s’agit de réaliser un câblage respectant un code couleurs:
o JAUNE: connexions des postes clients au réseau bureautique
o ROUGE: réseau automates/capteurs
o VERT: réseau GUEST wi-fi
o BLEU: réseau télécom
o BLANC: connexions des SERVEURS au réseau bureautique

 La majorité des machines (serveurs et postes) ont des accès à la fois au VLAN 10.4 et au VLAN 10.3
 La borne wi-fi du réseau GUEST Wi-fi se situe dans la salle de réunion de l'ECOTRON
Serveurs :
L’utilisation des ressources serveurs de l’Ecotron a été optimisée en s’appuyant sur des principes de virtualisation. Ces
ressources se décomposent en 4 serveurs physiques :
 ARCHIVE
 ZCTRLDOM0
 ZW2K8H1
 ZW2K8H2
Le détail des machines est décrit dans la figure ci-dessous :
Schéma global d’infrastructure

du SI de l’ECOTRON Wi-Fi Guest
VLAN 10.5
PC Utilisateur PC Utilisateur PC Utilisateur PC Utilisateur
Routeur/Firewall/VPN
FORTINET
AUTOMATES
Internet sDSL 2M
VLAN 10.3
X capteurs => Y variables
VM ‘DSC’ connectée à VLAN 10.4
DELL PowerEdge R710: 1x Intel Xeon QC E5620 2.4GHz/12Mo L3,
8x 4Go RAM, 4x 600Go SAS 15krpm 6Gbps, Windows Server 2008, X capteurs => Y variables
Vmware Server 2.0
- DSC: 2x vCPU 4.67GHz, 4Go RAM, 50Go vHDD Système DELL PowerEdge SC1430: 1x Intel Xeon
Windows XP SP3, 500Go vHDD Database CITADEL E5320 1.86GHz, 8Go RAM, Windows
- EDISandbox: 1x vCPU 2.33GHz, 2Go RAM, 50Go vHDD Server 2008 R2 / Hyper-V X capteurs => Y variables
Système Windows Server 2008 R2 + Application 1 VM utile (serveur de mails:
Apache/PHP VLAN 10.4 ZEXCHG2K7)
- PORTAILDB: 1x vCPU 4.67GHz, 4Go RAM, Stockage USB de backup: 2To
50Go vHDD Système Windows Server 2008 R1, 500Go X capteurs => Y variables
vHDD Database MySQL (GAM) + Application Apache/PHP VLAN 10.3
ARCHIVE Stockage USB local de backup: 2To zW2K8H1
X capteurs => Y variables
HP z400: 1x Intel Xeon W3520 2.67GHz, 4Go RAM, HDD partition DELL PowerEdge SC1430: 1x Intel Xeon
250Go Système Windows Server 2008 R2 / Hyper-V, HDD partition E5320 1.86GHz, 8Go RAM, Windows X capteurs => Y variables
1To Données Server 2008 R2 / Hyper-V
1 VM utile (serveur DNS) 3VM usage réservé à l’ECOTRON:
Stockage USB local de backup: 2To - zCTRLDOMv (Failover virtuel de
ZCTRLDOM0) X capteurs => Y variables
- ZSERVDIV
- ZSHPT (serveur SharePoint)
zCTRLDOM0 NAS Buffalo TeraStation: RAID-5 volume zW2K8H2 Stockage USB de backup: 2To
total 1.4To (environ 50% utilisé) ...
TS-RHTGL436
Figure 21: Schéma global d'infrastructure du SI de l'Ecotron
Remarque : Techniquement les automates ont une mémoire tampon interne (de 2Go) enregistrant en continu les
informations transmises par les capteurs distribués dans les différentes enceintes d’expérimentation. Cette mémoire
tampon donne potentiellement la capacité à l’Ecotron de supporter une interruption du serveur DSC sans perte de
données
Le serveur virtuel DSC héberge la base de données CITADEL, système critique pour le fonctionnement de la plateforme
Ecotron (base de données dépositaire des données brutes).
Stockage :
Un boitier NAS racké de marque BUFFALO assure la mise à disposition d’un espace de stockage partagé et sécurisé en
RAID-5 d’environ 1.4To sur le réseau.

Chaque machine dispose d’un volume de stockage suffisant pour assumer ses besoins localement. Tous les serveurs
disposent d’un disque dur local USB externe fournissant un gros volume (2TB) disponible pour la sauvegarde.
Ressources disponibles à la DSI :
La DSI locale du CNRS située sur le site Route de Mende propose des services payants d’hébergement d’applications
sur un système d’information entièrement virtualisé. Sous réserve de convenir des limites et conditions de la
prestation d’hébergement, les ressources disponibles sont les suivantes :
 128vCPU (dont environ 15 utilisées à ce jour)

 RAM « quasi-illimitée » disponible (à qualifier selon besoin)
 Espace de stockage de 96To sous-utilisé, dont 8To peuvent être réservés à l’usage de l’Ecotron si besoin
 Débits réseaux énormes fournis par RENATER (abonnement 100Mbps non restreint, 1Gbps exploité à ce jour,
possibles pics de débit gérés à 10Gbps sur demande)
La DSI nationale propose des services similaires mais par l’intermédiaire de contrat d’externalisation signé avec la
société BULL.
Flux de données :
Schématiquement, le flux de données expérimentales générées par les systèmes de l’Ecotron peut se représenter
linéairement comme suit :
Automates:
Acquisition
Données Enregistrement Données Traitement Qualité: Données Traitement Qualité (manuel): Données
Capteur toutes les (multiple de)
brutes 1 fois par heure brutes 1 fois par heure primaires Fréquence max tous les 2 jours secondaires
20 secondes
jusqu’à 1 heure
Figure 22: Schéma compact de flux de données
Les capteurs émettent leurs données vers des automates, équipés de contrôleurs dotés d’une « intelligence » propre
et d’une mémoire interne de 2Go. Les automates enregistrent leurs données brutes dans un système qui est copié 1
fois par heure. La copie est traitée à ce jour manuellement mais un objectif interne de gestion planifié tend à
automatiser ce traitement afin de générer de façon régulière et systématique des données primaires validées. Un
second niveau de traitement manuel, irrégulier et contrôlé par le Responsable Qualité des Données, a pour but de
corriger les valeurs hors scope et d’interpoler les valeurs absentes du système afin d’apporter au jeu de données le
statut de données secondaires.
En développant ce schéma, on voit ce que suit :
Fichiers Fichiers
Fichiers
de de
de
données données
données
CSV/MAT CSV/MAT
DB
DB Critères
Critères de
de Qualité
Qualité
Automates:
Acquisition
Données Enregistrement Données Traitement Qualité: Données Traitement Qualité (manuel): Données
Capteur toutes les (multiple de)
brutes 1 fois par heure brutes 1 fois par heure primaires Fréquence max tous les 2 jours secondaires
20 secondes
jusqu’à 1 heure
DB
DB CITADEL
CITADEL DB
DB GAM
GAM
Figure 23: Schéma éclaté de flux de données (vue de l'existant)
Les données brutes sont enregistrées par les automates dans la base de données CITADEL (format propriétaire
National Instruments de base de données historiques). Ces données brutes sont reportées par copie dans la base de

données MySQL appelée GAM et sont extraites en parallèle sous forme de fichiers aux formats CSV et MAT. Le
traitement destiné à générer les données primaires fait partie de l’application QCSettings et s’appuie sur la base de
données de critères de qualité. Ces données primaires sont générées sous forme de fichiers aux formats CSV et MAT.
Le retraitement manuel permettant de créer les données secondaires génère des fichiers aux formats CSV et MAT.
4.2 INVENTAIRE DES CONTRAINTES RELEVEES
L’accès réseau internet de l’Ecotron est limité par un débit faible (sDSL 2M). Un projet d'amélioration de l'accès à
Internet vers une ligne sDSL 4M symétrique est à l’étude. Ceci peut être obtenu sur demande à la région (qui paie
l'accès internet du bâtiment). De récents tests de trafic ont montré que la bande passante n’était pas saturée sauf en
cas de téléchargement, ce qui reste ponctuel.
La base de données du projet VALIDATE, référence technique de test destinée à évaluer le MAXIMUM de données
générées par un projet à l’Ecotron représente environ 30Go de données sur 1 an, soit l’enregistrement de moins de
4Mo par heure dans la base.
La plateforme Ecotron étant constituée de 3 plateaux, il est donc envisageable de voir tourner jusqu’à 3 projets en
parallèle sur la plateforme (1 par plateau) ce qui implique que :
 le volume de données maximal généré et enregistré dans la base est de 90Go par an (3x 30Go maximum).
 Le volume de données enregistré dans la base est de moins de 12Mo par heure.
Les 4 machines/Serveurs physiques hébergent environ 8 machines virtuelles dont l’usage est inégal. Le mot d’ordre de
l’Ecotron est de réserver ces machines à leur usage actuel et de ne pas envisager l’hébergement de la future
application à développer sur ces ressources.
La politique de la DSI nationale autorise à horizon de 2-3 ans sans difficulté l’hébergement de la future application de
l’Ecotron sur des ressources de la DSI Route de Mende (compatible avec les lignes stratégiques).
La question de l’administration (au niveau système) de la machine virtuelle qui doit héberger la future application de
l’Ecotron se pose : ça ne fait pas partie des prérogatives des opérateurs de la DSI Route de Mende.

ANNEXE 1 : PROCESSUS METIER GLOBAL (HORS ACTIVITE 5)
<<acteur>>
QCsettings
Client Directeur scientifique Directeur technique Responsable plateau Personnel Ecotron Responsable qualité
Activité 0: Soumission des projets Activité 1: Description des

Cahier des capacités de la
charges plateforme Ecotron
Décrire les
capacités des
Soumettre un Etudier le plateaux, du
projet projet laboratoire et
des services
du système
Demande de précisions
Accepter le
Non Capacités
projet?
Accès à la Oui
plateforme Activité 2: Conception de l’expérimentation
Créer le
projet
Se connecter
Spécifications
Spécifier le Etudier les

projet spécifications
Première
Non
validation?
Non
Deuxième
Oui Activité 3: Préparation de l’expérimentation
validaiton?
Tâches à
Oui
réaliser
Mettre en place
Activité 6.1: Consultation des données Préparer les critères qualité
Critères de
l’expérimentation
Consultation des données qualité
Sélectionner les
En fonction du rôle des utilisateurs Réaliser les
variables Non
tâches
Mettre en place
Tâches les modèles de
Modèles de
validées? reconstruction reconstruction
Sélectionner le Post-
post-traitement traitemetns
Oui
Activité 4: Suivi de l’expérimentation
Données Brutes
Lancer
Exporter les l’expérimentation Valider les
données et/ou les données
résultats Fichiers de
Données
données
primaires
Reconstruire
les données
Publier les
Données
données
Déclarer des secondaires
Activité 7: Constitution d’une base de reconstruites
incidents reconstruites
connaissances
Nouveaux Incidents Résoudre les

Consulter/Enrichir incidents
Scripts
la base de
connaissance
Activité 6.2:
Gestion des post-traitements
Télécharger les
Mettre en place
scripts Scripts les post-
traitements
exécutables
Figure 24: Processus métier global (hors activité 5)

CNRS ECOTRON Cahier Des Charges Specs V5 PDF

Transféré par

Informations du document

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

CNRS ECOTRON Cahier Des Charges Specs V5 PDF

Transféré par

Droits d'auteur :

Formats disponibles

CNRS ECOTRON UPS3248

1 Chemin du Rioux - Campus International de Baillarguet

Cahier des charges pour la mise en place d’une

Page 1 sur 62 Date : 8 août 2012

TABLE DES MATIERES ................................................................................................................................................. 2

TABLE DES FIGURES .................................................................................................................................................... 3

TABLE DES MAQUETTES .............................................................................................................................................. 4

1 PRESENTATION DU CAHIER DES CHARGES .......................................................................................................... 5

1.1 Contexte ............................................................................................................................................................ 5

1.2 Contenu du DOCUMENT ................................................................................................................................... 5

1.3 Schémas UML utilisés........................................................................................................................................ 6

1.4 Termes utilisés .................................................................................................................................................. 7

2 CONTEXTE, ACTEURS ET PROCESSUS METIERS ................................................................................................... 8

2.1 Contexte et acteurs ........................................................................................................................................... 8

2.2 Les Processus métiers de la plateforme Ecotron ............................................................................................ 11

3 MODELISATION DES BESOINS FONCTIONNELS DE L’ECOTRON ..........................................................................17

3.1 Activité 0 : Soumission des projets.................................................................................................................. 17

3.2 Activité 1 : description des capacités de la plateforme Ecotron ..................................................................... 18

3.2.1 Identification des acteurs et des cas d’utilisation ....................................................................................... 18

3.2.3 Analyse de l’UC 1.2 : « Regrouper et qualifier les capteurs » ..................................................................... 22

3.2.4 Analyse de l’UC 1.3 : « Décrire les ressources du laboratoire ».................................................................. 24

3.3 Activité 2 : Conception de l’expérimentation ................................................................................................. 25

3.3.1 Identification des acteurs et des cas d’utilisation ....................................................................................... 25

3.3.3 Analyse de l’UC 2.2 : « Spécifier l’expérimentation» .................................................................................. 27

3.3.4 Analyse de l’UC 2.3 : « Validation des spécifications » ............................................................................... 30

3.3.5 Analyse de l’UC 2.4 : « Valider l’expérimentation» .................................................................................... 32

3.4 Activité 3 : Préparation de l’expérimentation ................................................................................................. 33

3.4.1 Identification des acteurs et des cas d’utilisation ....................................................................................... 33

3.4.2 Analyse de l’UC 3.1 : « Gérer les tâches » ................................................................................................... 35

3.4.3 Analyse de l’UC 3.2 : « Réaliser les tâches » ............................................................................................... 38

Page 2 sur 62 Date : 8 août 2012

3.5 Activité 4 : Suivi de l’expérimentatioN ............................................................................................................ 40

3.5.1 Identification des acteurs et des cas d’utilisation ....................................................................................... 40

3.5.3 Analyse de l’UC 4.3 : « Publier les données reconstruites » ....................................................................... 43

3.6 Activité 5 : Gestion des interventions et des résultats d’analyse ................................................................... 45

3.6.1 Identification des acteurs et des cas d’utilisation ....................................................................................... 45

3.6.2 Analyse de l’UC 5.1 : « Demander des interventions » ............................................................................... 46

3.6.3 Analyse de l’UC 5.2 : « Gérer les demandes d’interventions » ................................................................... 47

3.7 Activité 6 : Consultation des données et gestion des post-traitements ......................................................... 51

3.7.1 Identification des acteurs et des cas d’utilisation ....................................................................................... 51

3.8 Activité 7 : Constitution d’une base de connaissances ................................................................................... 55

3.8.1 Identification des acteurs et des cas d’utilisation ....................................................................................... 55

3.8.2 Analyse des UC de l’activité 7 ..................................................................................................................... 56

4 ETUDE DES RESSOURCES INFRASTRUCTURELLES INFORMATIQUES DE L’ECOTRON ...........................................58

4.1 Inventaire des ressources existantes .............................................................................................................. 58

4.2 Inventaire des contraintes relevées ................................................................................................................ 61

ANNEXE 1 : PROCESSUS METIER GLOBAL (HORS ACTIVITE 5) .....................................................................................62

TABLE DES FIGURES

Figure 1: Diagramme de contexte : acteurs et flux de données ....................................................................................... 10

Figure 2: Diagramme d'acteurs ......................................................................................................................................... 10

Figure 4: Processus métiers - activité 3 « Préparation de l’expérimentation » ................................................................ 13

Figure 5: Processus métiers - activités 4 « Suivi de l’expérimentation » .......................................................................... 14

Page 3 sur 62 Date : 8 août 2012

Figure 8: Cas d'utilisation de l'activité 0 : « Soumission des projets ».............................................................................. 17

Figure 12: cas d'utilisation de l'activité 2 : « Conception de l’expérimentation » ............................................................ 26

Figure 13: DSS de l'UC 2.2 « Spécifier l’expérimentation » .............................................................................................. 29

Figure 15: Cas d'utilisation de l'activité 3 « Préparation de l'expérimentation » ............................................................. 34

Figure 16: DSS de l'UC 3.1 « Gérer les tâches » ................................................................................................................ 37

Figure 17: cas d'utilisation de l'activité 4 « Suivi de l’expérimentation » ......................................................................... 41

Figure 23: Schéma global d'infrastructure du SI de l'Ecotron ........................................................................................... 59

Figure 24: Schéma compact de flux de données .............................................................................................................. 60

Figure 25: Schéma éclaté de flux de données (vue de l'existant) ..................................................................................... 60

Figure 28: Processus métier global (hors activité 5) ......................................................................................................... 62