Proposition d’intégration de systèmes didactiques dans une plateforme d’apprentissage

Les EIAH : Support Informatique dans la formation à distance

On ne peut pas parler de la formation à distance sans parler des EIAH (Environnement Informatique pour l’Apprentissage Humain). Ils sont indispensables pour faire de la formation à distance. Un EIAH est un environnement informatique conçu dans le but de favoriser l’apprentissage humain, c’est-à-dire la construction de connaissance chez un apprenant. En effet l’e-formation est entièrement médiatisée par les ordinateurs et les réseaux électroniques. Au début de l’informatique, dans les années 1970 les EAO (Enseignement Assisté par Ordinateur) sont apparus mais ne permettaient que l’affichage du contenu pédagogique.
Puis avec les progrès fait dans l’intelligence artificielle et des sciences cognitives, sont ensuite venus les EIAO (Environnement Intelligemment Assisté par Ordinateur) qui eux étaient capables de donner un ordre aux leçons destinées à l’apprenant, donc plus de dialogue d’interaction entre l’environnement et l’apprenant. Comme nous l’avons vu dans la section précédente avec l’avènement des TICE, ce sont développés les EIAH.
C’est un environnement qui intègre des agents humains (apprenant et formateur) et artificiels (informatique) et leur offre des conditions d’interactions locales ou à travers des réseaux informatiques ainsi que des conditions d’accès à des ressources formatives (humaines et ou médiatisées) locales ou distribuées [BENMOHAMED, 2007]. Un EIAH a pour objectif de favoriser des apprentissages, de les accompagner et de les valider.

Le monde des Automates Programmable Industriels

Le marché des API est dominé par les constructeurs Schneider-Electric, Siemens et Rockwell.
Dans le domaine de l’éducation, Schneider-Electric reste le constructeur le plus impliqué. Il présente de nombreux avantages pour les enseignants : des prix attractifs et une certaine facilité de mise en place. La plupart des systèmes automatisés didactiques sont donc équipés d’automate de la marque Schneider-Electric.

Fonctionnement d’un API

Un APIest un dispositif électrique destiné à la commande de processus industriel. Pour cela un programme est installé sur l’API et tourne de façon cyclique. En fonction des données récupérées sur les capteurs, sondes ou autres (on parle des entrées), le programme de l’automate réagit et met à jour les actionneurs nécessaires (on parle des sorties). La figure 4 illustre le fonctionnement d’un API.

Programmation de l’API

L’écriture d’un programme correspond à l’établissement du cycle d’un système automatique. Pour représenter le fonctionnement du système automatisé, on utilise le langage graphique GRAFCET (Graphe de Commande Etape Transition). Il permet de représenter chaque étape du fonctionnement du système sur lesquelles on associe une ou plusieurs actions à réaliser.
Après avoir fait le GRAFCET du système automatisé, on s’appuie sur un langage de programmation pour coder les actions associées aux étapes. On utilise généralement le Ladder, langage graphique ressemblant aux schémas électriques ou le List, langage textuel assez proche de l’assembleur. Le ladder pour des raisons de facilité est le plus souvent choisi par les automaticiens.

Les Variables

Ce sont les variables créées pour le programme de l’API par l’automaticien qui vont nous permettre d’interagiravec l’API.
Les différents types d’une variable dans un programme automate peuvent être le booléen (BOOL – 1 bit), l’entier(INT – 16 bits), le mot(WORD – 16 bits), le double mot(DWORD – 32 bits), la chaîne de caractères(STRING), le nombre à virgule flottante(REAL sur 32 bits), le TIME(correspond au nombre de secondes, codé sur 32 bits) ou les tableaux(ARRAY).
La mémoire des données de l’automate est découpée en deux ensembles distincts, les bits et les registres. Les variables de type booléen seront stockées dans la zone bit tandis que les autres types de variables (entier, réel, time, string, mot, double mot et tableau) seront stockées dans la zone registre sur 1 ou plusieurs registres ou chaque registre équivaut à 16 bits. Pour exemple, le réel étant codé sur 32 bits, il sera stocké sur 2 registres.
Il existe plusieurs types de variables, les variables internes au programme, les constantes, les variables systèmes qui nous donnent des informations sur le système, mais également les variables pour les entrées et sorties physiques de l’automate.
Quel que soit le type de variable, le format des adresses des variables sera toujours le même : %Vtn ou V représente le type de variables (M pour variable interne, K pour constante, S pour variable système, I pour entrée physique de l’automate, Q pour sortie physique de l’automate), treprésente la typologie d’une variable (X pour un bit, W pour un mot, D pour un mot double et b pour octet) et nle numéro de la variable dans la mémoire des données.

Les réseaux industriels locaux

Les réseaux industriels locaux ou bus de terrain permettent de faire dialoguer des équipements industriels nombreux et divers (capteurs, actionneurs, API, informatique) en intégrant une caractéristique importante, celle de fournir des services contraints par le temps avec souvent du temps réel. C’est avec ces bus de terrain que la communication avec les API des systèmes est possible.
Ils se déclinent sous quatre niveaux. Le plus bas niveau (niveau 0) correspond à la communication entre les actionneurs, capteurs et API au sein d’un système, le niveau 1 représente la communication entre les API et les modules d’interface pour la commande de mouvement tels que les variateurs de vitesse ou démarreur, le niveau 2 la communication entre les API, et le niveau le plus haut (niveau 3) représente généralement la communication entre les API et un poste informatique.
On peut constater que notre problématique se situe au dernier et troisième niveau. Cette communication est possible grâce à l’existence de protocoles comme Modbusou ProfiBus.
Ces deux derniers étant considérés comme les principaux de leur catégorie. Tout ceci a pu prendre forme par l’adoption progressive de standards communs entre les mondes de l’informatique et de l’automatisme ce qui a fait tomber la frontière entre ces deux mondes. La communication entre ceux-ci converge grâce à l’adoption de protocoles standards mondiaux comme Ethernet et TCP/IP (Transmission Control Protocol/Internet Protocol). Ethernet est un protocole connu, largement implémenté et ses performances augmentent continuellement avec l’évolution des technologies (notamment sa bande passante).

ProfiBus

ProfiBus (Process Field Bus) est le nom du protocole de communication inventé par Siemens.
Il s’agit d’un protocole propriétaire, il est donc intégré quasi exclusivement dans les automates Siemens.
A ce jour, on trouve deux variantes du protocole, où la différence se trouve essentiellement dans le mode de transmission. En effet, les deux variantes échangent le même type de trames.
ProfiBus-DP (Decentralized Peripherals / Périphériques décentralisés) : à ce jour, c’est la variante la plus utilisée. Il est basé sur la transmission RS-485 (possibilité de débit de l’ordre de 12 Mbits/secondes)
ProfiBus-PA (Process Automation / Automatisation de Processus) : conçu pour les zones à risques (d’explosion notamment), il utilise la transmission MBP (limité à un débit de 31 Kbits/secondes).

Les environnements ayant proposés des TéléTP sur des systèmes didactiques

Au début du 21eme siècle les téléTP ont commencé à émerger dans les travaux de recherche pour combler les manques de la formation à distance dans ce domaine-là. Une diversité de projets ou d’études de faisabilité traitant des téléTP dans divers domaines ont vu le jour résultant pour la plupart en environnement propriétaires et utilisables uniquement dans le laboratoire ou l’université à l’origine du projet. C’est pourquoi malgré de nombreux sites traitant des téléTP que nous avons vu sur Internet, peu sont visibles et donc encore moins en démonstration.
Nous avons fait l’étude de quatre projets nous permettant de retracer le panorama des solutions existantes en terme de téléTP. Nous avons écarté toutes les applications permettant la télémanipulation via la simulation de systèmes. Nous avons pris en compte uniquement les environnements proposant des téléTP sur des systèmes réels ou didactiques et ayant une intention pédagogique. Tous ces projets ont été réalisés par des laboratoires de recherche ou bien par des enseignants.
Cette étude est nécessaire afin de comprendre ce qui a déjà été réalisé dans ce domaine -là et d’analyser comment l’utilisation des systèmes a été pensée d’un point de vue technique dans le but de faire des téléTP.

Cas d’étude

Ce mémoire a été réalisé au sein de la société DMS que nous présenterons dans la section suivante. Pour DMS, « la prise en compte des Technologies de l’Information et de la Communication dans l’éducation suppose une évolution profonde du système éducatif». En effet le développement du numérique doit conduire à terme à l’évolution de l’organisation des enseignements et des pratiques pédagogiques.
C’est dans le cadre du développement de ses activités sur l’enseignement que DMS a souhaité réaliser une plateforme d’apprentissage en ligne intitulée DIWEB(DIdactique WEB) permettant la mise à disposition des apprenants d’un ensemble de ressources pédagogiques pouvant être matériels (systèmes didactiques) ou immatériels (cours, Travaux Dirigés, Travaux Pratiques, …) sur un ensemble de matières pour les formations professionnelles et technologiques.

Le panneau photovoltaïque

Au sein de DMS, le système didactique qui a été mis à notre disposition pour réaliser les expériences a été un panneau photovoltaïque.

Présentation et Fonctionnement

Tous les jours, le soleil fournit de l’énergie à la Terre. On peut utiliser cette énergie gratuite grâce à une technologie appelée photovoltaïque, qui transforme l’énergie solaire en électricité. Les modules ou panneaux photovoltaïques sont composés de semi-conducteurs qui permettent de transformer directement la lumière du soleil en électricité.
Ces modules peuvent s’avérer une source d’énergie sûre, fiable, sans entretien et non polluante pendant très longtemps. La majorité des modules sur le marché aujourd’hui sont pourvus de garanties de plus de 20 ans, et ils fonctionneront bien au-delà de cette période.

Proposition d’intégration de systèmes didactiques dans une plateforme d’apprentissage

En s’intéressant à l’intégration des systèmes automatisés didactiques dans une plateforme d’apprentissage, nous nous sommes donc recentrés sur la partie téléTP de DIWEB. Dans cette section nous ferons une analyse sur l’organisation et le déroulement des TP en présentiel pour les formations professionnelles et technologiques afin de savoir comment il est possible de l’adapter aux téléTP. A partir de là, nous pourrons dégager les spécifications qui recenseront l’ensemble des fonctionnalités à développer. Enfin nous ferons une proposition d’architecture permettant d’intégrer des systèmes automatisés didactiques dans une plateforme d’apprentissage. Ces systèmes seront regroupés dans un laboratoire distant.

Observabilité du système lors de la manipulation

Le fait de ne pas avoir une vision du système lors d’une manipulation à distance peut constituer un problème majeur. En effet, pouvoir observer le système évoluer en fonction des actions lancées peut permettre aux apprenants de comprendre certaines notions qu’ils ne pourraient pas comprendre si le système n’était pas visible. Ceci peut être pallié par l’installation de dispositifs environnementaux comme une caméra ou un micro qui peuvent reproduire la vue et l’écoute autour des systèmes en fonctionnement. Il sera beaucoup plus compliqué voire impossible en revanche de reproduire l’odeur ou le toucher, ce qui sur certaine manipulation peut poser un problème.
La reproduction du système peut être également envisagée avec l’usage d’images virtuelles en 2 ou 3 dimensions.

Sécurité des systèmes

La sécurité des systèmes mais également des humains peut être problématique. En effet, on peut imaginer que pendant une manipulation à distance faite par des apprenants, le système subisse une panne technique ce qui peut emmener des comportements non maitrisés et dangereux du système. Il paraît donc peu probable de laisser l’utilisation des systèmes à distance aux apprenants 24h/24. Une présence humaine serait donc souhaitable durant les périodes d’utilisation des systèmes.

 

Le rapport de stage ou le pfe est un document d’analyse, de synthèse et d’évaluation de votre apprentissage, c’est pour cela rapport-gratuit.com propose le téléchargement des modèles complet de projet de fin d’étude, rapport de stage, mémoire, pfe, thèse, pour connaître la méthodologie à avoir et savoir comment construire les parties d’un projet de fin d’étude.

Table des matières
Remerciements 
Abréviations
Glossaire 
Table des matières
Introduction
I. Etat de l’art 
1. L’évolution de la formation à distance
1.1. De la formation à distance à la formation ouverte et à distance
1.2. L’arrivée de l’e-formation
1.2.1. Les téléTP
1.2.2. Enjeux
1.3. Les EIAH : Support Informatique dans la formation à distance
2. Le pilotage des systèmes didactiques
2.1. Le monde des Automates Programmable Industriels
2.1.1. Fonctionnement d’un API
2.1.2. Programmation de l’API
2.1.3. Les Variables
2.2. Les réseaux industriels locaux
2.2.1. ProfiBus
2.2.2. Modbus
2.3. L’IHM de commande
3. Les environnements ayant proposés des TéléTP sur des systèmes didactiques
3.1. TPLine
3.2. EVARISTE
3.3. ICTT@Lab
3.4. eINST
II. Cas d’étude
1. La société DMS
2. Le projet DIWEB
3. Le panneau photovoltaïque
3.1. Présentation et Fonctionnement
3.2. Composition
3.3. Les dispositifs environnementaux
3.4. Utilisation
III. Proposition d’intégration de systèmes didactiques dans une plateforme d’apprentissage
1. Analyse
1.1. Organisation des TP en présentiel
1.2. Déroulement des TP en présentiel
2. Spécifications
2.1. Besoins
2.1.1. Contrainte temporelle
2.1.2. Observabilité du système lors de la manipulation
2.1.3. Sécurité des systèmes
2.1.4. Temps de manipulation d’un système
2.1.5. Créneaux Horaires
2.2. Fonctionnalités
2.2.1. L’Apprenant
2.2.2. L’Administrateur
2.2.3. Le formateur
2.3. Modélisation
2.3.1. Les cas d’utilisation
2.3.1.1. Cas d’utilisation « Réaliser l’expérimentation et la collecte de résultats d’un TP »
2.3.1.2. Cas d’utilisation « Interpréter les résultats d’une manipulation »
2.3.1.3. Cas d’utilisation « Administrer un laboratoire distant »
2.3.1.4. Cas d’utilisation « Administrer des systèmes didactiques »
2.3.1.5. Cas d’utilisation « Administrer l’utilisation des systèmes »
2.3.2. Diagramme de déploiement
2.3.3. Diagramme de classes
2.3.3.1. La couche Laboratoire
2.3.3.2. La couche Système
2.3.3.3. La couche IHM de commande
2.3.3.4. La couche Actions
2.3.3.5. La couche Proxy
2.3.4. Diagramme de composants
IV. La conception 
1. Réseau Informatique d’un établissement
2. Choix techniques sur la communication avec les automates
2.1. Communication en TCP/IP entre le serveur web et l’automate
2.2. Communication en Modbus TCP/IP entre le serveur web et l’automate
2.2.1. La bibliothèque libModbus
2.2.2. La bibliothèque JModbus
2.2.3. La bibliothèque Modbus4j (Modbus For Java)
2.3. Le service WebDesigner
2.4. Choix du type de communication utilisé
V. Réalisation et Expérimentation
1. Installation et mise en place du réseau au sein de la société DMS
1.1. Accès à distance au système panneau photovoltaïque
1.2. Configuration du routeur
1.3. Port forwarding et Iptables
2. Développement de la plateforme DIWEB
2.1. Choix du langage de développement
2.2. Le Design Pattern Modèle Vue Contrôleur
3. Développement de la solution proposée
3.1. Organisation du développement
3.2. Développement
3.2.1. Développement des IHM de commande du panneau photovoltaïque
3.2.2. Le pilotage du système panneau photovoltaïque
3.2.3. Observation de la manipulation
3.2.4. Affichage du flux vidéo et audio
4. Expérimentation de la solution proposée
Conclusion 
Annexe : La modélisation UML 
Références Bibliographies 
Table des illustrations

Rapport PFE, mémoire et thèse PDFTélécharger le rapport complet

Télécharger aussi :

Laisser un commentaire

Votre adresse e-mail ne sera pas publiée. Les champs obligatoires sont indiqués avec *