See discussions, stats, and author profiles for this publication at: https://www.researchgate.

net/publication/258243012

Sensibilisation à la modélisation SART pour le développement de code temps

réel

Conference Paper · March 2013

CITATIONS READS

0 1,000

1 author:

Daniel Chillet
IRISA - Institut de Recherche en Informatique et Systèmes Aléatoires
124 PUBLICATIONS   741 CITATIONS   

SEE PROFILE

Some of the authors of this publication are also working on these related projects:

RTOS Modeling View project

All content following this page was uploaded by Daniel Chillet on 30 November 2015.

The user has requested enhancement of the downloaded file.

Sensibilisation à la modélisation SART pour le développement
de code temps réel
Daniel Chillet
ENSSAT - Université de Rennes 1 - CAIRN/IRISA/INRIA
BP 80518 - 6 rue de Kerampont - F22305 Lannion - France
Daniel.Chillet@univ-rennes1.fr
Résumé—Le développement de code pour des systèmes de contrôle
est un élément important de la formation des ingénieurs de l’Enssat
et un enseignement spécifique est assuré sur cette partie en seconde
année du cycle de formation. Dans le temps accordé à cet enseignement,
nous nous attachons à sensibiliser nos étudiants à la problématique de
la modélisation de la solution avant le passage au code. La difficulté
que nous rencontrons est assez largement répandue et est liée à la
tentation pour les étudiants d’aller trop vite vers l’écriture de lignes
de code, sans avoir au préalable décrit/modélisé une solution complète.
Cela engendre de nombreux tests et corrections conduisant généralement
à un code difficilement maintenable et incompréhensible. Pour répondre
à ce problème, nous avons développé un outil qui permet de mieux
comprendre que l’important dans un contexte de développement de code
n’est pas le code lui même, mais la partie qui détaille la solution à coder.
En proposant un outil permettant de modéliser des solutions simples,
au travers de l’utilisation des réseaux de Pétri animés, il est possible
de vérifier que la solution produite répond bien au cahier des charges.
La modélisation devient alors naturellement le support d’échange entre
l’étudiant et l’encadrant et permet de se mettre d’accord sur les
fonctionnalités de la solution. Une fois cette étape validée, l’étudiant peut
alors se lancer dans le codage de la solution, phase qui requiert alors
d’autres compétences relative cette fois-ci à une bonne connaissance de
l’operating system utilisé.
I. I NTRODUCTION
L’enseignement des méthodologies de conception pour des
systèmes de contrôle passe généralement par plusieurs phases qui
sont la compréhension du cahier des charges, la modélisation d’une
solution répondant à ce cahier des charges et enfin l’écriture du code
respectant cette modélisation. Notons que pour la dernière phase, des
outils de génération de codes peuvent être utilisés et aider à produire
soit le squelette de l’application, soit un code plus détaillé. Les
étapes qui posent généralement problème sont celles qui permettent
d’établir la modélisation d’une solution. Cette partie est délicate pour
plusieurs raisons, tout d’abord parce qu’imaginer une solution est
un exercice difficile demandant une réflexion et une abstraction que
les étudiants ne maitrisent généralement pas. De plus, les étudiants
ont trop souvent l’impression d’avoir compris ce qui devait être
développé et ils se lancent généralement beaucoup trop tôt dans
le développement du code. Cette précipitation conduit alors à des
corrections et des ajustements au fur et à mesure du développement
du code pour prendre en compte des choses qui n’avaient pas été
comprises au départ. Si cette méthodologie de travail peut donner de
bons résultats sur des exemples simples, elle conduit par contre à de
réelles difficultés de développement pour des applications complexes,
découpées en nombreuses sous fonctionnalités.
Pour tenter de sensibiliser au mieux les étudiants à cette
problématique, il faut donc soumettre aux étudiants un cahier des
charges avec un minimum de complexité afin que le passage par
une méthodologie de conception soit ressenti comme un plus et
non pas comme une contrainte. Il s’agit alors de montrer que
lorsqu’une solution a été modélisée, il ne reste plus qu’à effectuer
le développement du code, travail qui incombe plutôt au technicien
qu’à l’ingénieur d’ailleurs.
Pour répondre à cette problématique, nous avons développé un
outil permettant de modéliser des solutions sous la forme de réseaux
de Pétri. Cet outil permet de visualiser les réseaux de Pétri modélisés
et assure leur animation en lien avec le système à contrôler. Le
réseau de Pétri est décrit en XML et il est permet de se connecter via
un driver au système à contrôler. Le système à contrôler est quant
à lui modéliser par une interface graphique et permet de se passer
du système réel et de simplifier les aspects tests et vérifications.
L’outil qui supporte la simulation du réseau de Pétri est décrit en
Python, et les interfaces des systèmes à piloter sont décrites en Java.
Ces interfaces sont livrées aux étudiants et l’outil de simulation de
réseaux de Pétri est utilisé en mode illustration à partir de quelques
réseaux de Pétri proposés par les étudiants. L’objectif de cet outil
n’est pas la vérification des contraintes temps réel, celles-ci pourront
être vérifiées directement dans les outils de développement fournis
avec l’operating system utilisé.
Cet article présente, dans la section II, l’outil développé et mis
à disposition des étudiants lors des séances de modélisation. La
section III présente quant à elle le travail qui est demandé aux
étudiants durant les projets de développement d’applications temps
réel. L’impact de l’utilisation de l’outil est ensuite commenté dans la
section V. Finalement, la section VI conclut cet article.
II. P R ÉSENTATION DE L’ OUTIL DE SIMULATION DE R ÉSEAUX DE
P ÉTRI
L’outil de simulation des réseaux de Pétri est une interface gra-
phique qui permet d’afficher le réseau dans son ensemble (voir
figure 1), en précisant les transitions entre les places. Les transitions
contiennent à la fois les conditions de transitions ainsi que les actions
à réaliser lors du franchissement de ces transitions.
Une fois l’outil lancé, le réseau de Pétri sélectionné est graphique-
ment affiché. L’outil ouvre ensuite un socket et se place en attente
de connexion et d’ordres en provenance d’un client sur ce socket.
L’outil se comporte alors comme un serveur de simulation de réseaux
de Pétri, voir la première séquence d’évènements présentée dans le
diagramme de séquence de la figure 3.
Les commandes qui sont envoyées entre le client et le serveur, sont
constituées de messages textuels, indiquant les événements provoqués
par le système à piloter (signal venant d’un capteur par exemple),
l’interface transfert ces informations reçues vers le réseau de Pétri,
qui peut alors franchir une ou plusieurs transitions. Les actions
provoquées par le franchissement des transitions peuvent être de
nature à piloter un actionneur (un moteur, une vanne, etc), cette action
est alors traduite en un message textuel qui est alors retourné vers le
système à piloter.
Le système à piloter doit disposer d’un driver permettant de
simplifier les interactions avec le serveur assurant la simulation
du réseau de Pétri. Un driver générique est proposé aux étudiants
 F IGURE 2. Exemple d’un réseau de Pétri simple permettant de piloter un
moteur.

F IGURE 1. Vue générale de l’interface graphique représentant le réseau de l’ordre de démarrage du moteur. Cette action est alors renvoyée, au
Pétri permettant le contrôle du système. travers du serveur et du driver vers le contrôle de l’application qui
appel simplement la fonction StartMotor(). Le réseau de Pétri
se trouve alors dans l’état présenté à la figure 4.
qu’ils doivent paramètrer à l’aide d’un tableau de commandes et
d’évènements, ce driver doit ensuite être initialisé dans le code
applicatif que développe l’étudiant.
Une fois le système initialisé, c’est-à-dire le serveur et l’application
contrôlant le système connectés (phase 1 du diagramme de séquence),
l’opérateur déclenche un démarrage de l’application de contrôle du
système à piloter. Supposons que le système à piloter soit un simple
moteur (permettant le déplacement d’un chariot sur un parcours
spécifique), et que le contrôle consiste simplement à attendre un
ordre Start de la part de l’opérateur, déclenchant le démarrage
du moteur, et que celui-ci s’arrête lorsque qu’un capteur (de fin de
course par exemple) se déclenche. Dans ce cas, le réseau de Pétri
correspondant est tel que celui présenté dans la figure 2. Dans cette
figure, les fonctions receive(...) et send(...) correspondent
aux réceptions et envois de messages entre le serveur et le client. La
fonction receive(’sensor’) correspond par exemple à l’attente
d’un signal en provenance du capteur de fin de course du chariot.
Cette fonction sera vrai/true lorsque cet évènement sera reçu
par le serveur. Les fonctions send(’StartMotor’) ainsi que F IGURE 4. Evolution du réseau de Pétri simple permettant de piloter un
send(’StopMotor’) provoqueront quant à elles l’envoi de mes- moteur, après que l’ordre de démarrage ait été donné par l’opérateur.
sages vers le client.
Dans le diagramme représenté à la figure 3, l’opérateur déclenche, La suite du diagramme de séquence présente le déclenchement
depuis son boitier de commande, un ordre de démarrage du système de l’évènement Sensor correspondant, par exemple, à la détection
(Start). Le réseau de Pétri indique que la réception de cet ordre d’une butée de fin de course (consécutif au déplacement d’un
receive(’start’) provoque le franchissement de la transi- chariot par exemple). Dans cette nouvelle séquence, la séquence
tion t1, ce franchissement provoque alors l’envoi d’un ordre de d’évènements est presque identique et débute par un évènement
démarrage au moteur send(’StartMotor’), ce qui se traduit (Sensor) envoyé directement vers le réseau de Pétri via le dri-
par un appel à la fonction driver du moteur. ver et le serveur. Le réseau de Pétri reçoit alors l’information
D’un point de vue diagramme de séquences, le fonctionnement est de déclenchement de l’évènement et évalue alors les transitions à
alors le suivant, l’ordre de démarrage déclenché par l’opérateur est franchir, s’il y en a. Dans notre exemple, la transition t3 devient
récupéré par l’application de contrôle. Celle-ci envoie alors cet ordre franchisage. Le simulateur de réseaux de Pétri provoque alors le
vers le réseau de Pétri au travers du driver et du serveur supportant la franchissement de cette transition, et génère alors un jeton dans la
simulation du réseau. Cet ensemble d’opérations provoque l’arrivée place p3. Cet ensemble transition t3 et place p3 permet de modéliser
d’un nouvel évènement dans le réseau, qui voit sa transition t1 la prise en compte d’une interruption, et cette interruption est capturée
franchissable. Le réseau déplace alors le jeton de la place p1 vers par la place p3, et conduit le réseau de Pétri dans l’état représenté à
la place p2, et déclenche alors l’action de la transition t1, à savoir la figure 5.
F IGURE 3. Diagramme de séquence illustrant la connexion du serveur de simulation de réseaux de Pétri et de l’application réalisant le contrôle du système..
La présence d’un jeton dans la place p3 et d’un jeton dans la
place p2 permet alors au simulateur de provoquer le franchissement
de la transition t2 qui déclenche alors l’action associée, c’est-à-dire
l’action d’arrêt du moteur (send(’StopMotor’)). À noter sur
la figure 5 que la transition t2 est de couleur verte, indiquant que
cette transition est franchissable. Une fois cette transition franchit, le
réseau se trouve alors dans l’état représenté par la figure 6.
Si le diagramme de séquences permet de décrire l’enchainement
des fonctions à appeler pour assurer une prise en compte complète
d’un évènement, le réseau de Pétri simplifie la vue et ne montre que
l’aspect fonctionnel du contrôle. Le travail des étudiants consiste à
définir cet aspect fonctionnel, et l’idée est de leur monter qu’une fois
le réseau décrit, celui-ci peut tout à fait être utilisé pour vérifier le
bon fonctionnement du contrôle du système.
III. T RAVAIL À R ÉALISER PAR LES ÉTUDIANTS
Les projets que nous proposons aux étudiants correspondent à
des systèmes de production d’une complexité suffisante pour que
le développement immédiat du code ne soit guère facilité. Le ca-
hier des charges est volontairement ambigüe et souffre de manque
d’explications sur certains points et de trop d’informations inutiles
sur d’autres points. Nous demandons aux étudiants de réfléchir, dans
un premier temps à une décomposition du problème en plusieurs
grandes fonctions. L’objectif consiste à sensibiliser les étudiants au
fait que dans un problème complexe, il y a bien souvent un cœur
de problème à résoudre et que viennent ensuite des compléments,
compléments qui n’ont de sens que si le cœur du problème est géré.

F IGURE 5. Evolution du réseau de Pétri simple permettant de piloter
un moteur, après la réception de l’évènement de fin de course provoquant
l’interruption modélisée sur la gauche de la figure.
F IGURE 6. Evolution du réseau de Pétri simple permettant de piloter un
moteur, après franchissement de la transition t2 provoquant l’arrêt du moteur.
Il n’est par exemple pas prioritaire de s’intéresser à la vitesse du
chariot si la gestion de son démarrage et de son arrêt ne sont pas
gérés correctement.
À partir de leur modélisation, les étudiants produisent un document
qui est remis à l’encadrant et une présentation orale permet de faire un
point afin de discuter de l’orientation prise pour définir la solution. Il
s’agit là non pas de corriger la modélisation et de donner une solution
au problème, mais plutôt de critiquer la modélisation proposée au
regard du problème posé.
À l’issue de cette présentation, quelques exemples de modélisation
sont sélectionnés pour être simuler par notre outil afin de montrer que
le travail de réflexion est alors terminé. Cette partie fait l’objet d’une
présentation par l’enseignant à partir d’au minimum deux solutions
proposées par les étudiants. Pour illustrer l’importance de cette phase
de modélisation, au moins une solution correcte et une incorrecte sont
utilisées. L’objectif étant de montrer que cette étape va permettre de
détecter des problèmes dans le contrôle du système, d’un point de
vue fonctionnel. Une réflexion est alors entamée avec les étudiants
sur la façon dont le système doit être stimulé afin de valider son
bon fonctionnement. L’enseignant insiste ensuite sur le fait que la
validation fonctionnelle n’établit en rien que le codage sera en mesure
de piloter le système en respectant l’ensemble des contraintes. Les
étudiants poursuivent alors le projet par une phase de codage de leur
solution, éventuellement modifiée sir le besoin s’en faisait sentir.
Au terme du projet, les étudiants produisent un document final
englobant à la fois la modélisation, les explications concernant le
passage au code et les tests réalisés (sous forme de trace d’exécution).
L’évaluation globale du projet tient compte de tous ces éléments,
et une grosse part de la notation est attribuée à la cohérence globale
entre la modélisation et le code développé. Les étudiants pour lesquels
le code de la solution ne respecte pas la modélisation sont fortement
pénalisés. Le message que nous souhaitons passer au travers de
l’évaluation de la cohérence consiste à dire que si le travail de
modélisation est correctement fait et validé, alors la partie codage
doit suivre cette modélisation. Nous sensibilisons les étudiants au
fait que beaucoup d’outils sont actuellement proposés pour produire
du code à partir d’une modélisation et que dans ce cas, la structure du
code est évidemment en parfaite cohérence avec cette modélisation.
La question qui se pose concerne la raison pour laquelle nous
n’utilisons les outils disponibles, notamment des outils commerciaux
ou universitaires éprouvés. Notre réponse, qui peut être critiquable
consiste à dire que l’utilisation massive d’outils, notamment pour
produire du code automatiquement, ou semi-automatiquement, ne
peut être vraiment profitable que si les méthodes et techniques sous
jacentes sont maitrisées. Nous pensons qu’avant de pouvoir utiliser
intelligemment de tels outils, il est important d’avoir pratiqué à partir
d’outils ne masquant pas toute la complexité du système. D’où l’idée
de passer par un outil simple, ne produisant aucun code.
Comme cela a été mentionné plus haut, une attention particulière
est portée sur les tests réalisés, et les étudiants sont aussi très
fortement sanctionnés s”ils sont dans l’impossibilité de démontrer
que leur développement est correct. Ce point est souvent sujet à ques-
tionnement de la part des étudiants, et le passage par la modélisation
et la vérification de cette modélisation leur permet de se poser la
question du test beaucoup plus tôt, et de lever des questions sur la
compréhension globale du système bien avant la phase d’écriture du
code à proprement parler. Sur ce point, nous insistons sur l’intérêt
du travail au niveau modélisation plutôt qu’au niveau du code. Ce
niveau d’abstraction permet en effet de s’affranchir des problèmes
directement liés à la syntaxe, et de vraiment se concentrer sur les
fonctionnalités, ces dernières correspondant aux réelles attentes du
client.
IV. E XEMPLES DE CAHIER DES CHARGES
Les exemples que nous proposons aux étudiants concernent dans
un premier temps un problème très simple ayant pour objectif de
piloter le positionnement de deux grues à l’aide d’une console de
commande. Il s’agit ici surtout de leur donner un exemple complet,
qui leur permet de manipuler sur un exemple simple et leur faire
comprendre que la modélisation par réseau de Pétri de la solution
peut tout à fait être utilisée pour vérifier la fonctionnalité du système
à développer.
Le code C permettant de piloter les grues est aussi fourni et sera
bien souvent utilisé par les étudiants comme un point de départ pour
le développement du code de leur projet.
La figure 7 présente un exemple de système qui est proposé aux
étudiants, le texte ci-dessous donne une illustration de la présentation
du cahier des charges qui est donné aux étudiants et à partir duquel
ils doivent construire une solution.
A. Premier exemple de cahier des charges
Un petit village breton soucieux de montrer l’exemple et de
participer activement à la diminution de son empreinte écologique, a
décidé d’étudier un système de chauffage des bâtiments publics basé
sur l’utilisation d’un chauffe eau solaire. Le village est soumis à des
ensoleillements assez réguliers, et des relevés ont montré qu’il était
envisageable de récupérer suffisamment d’énergie pour chauffer la
mairie et l’école.
Le système envisagé par le maire du village est composé d’un
chauffe eau solaire et d’un système de stockage (ballon d’eau chaude)
afin de pouvoir emmagasiner de l’énergie lorsque l’ensoleillement est
maximum et la restituer lorsque les besoins s’en font sentir. Lorsque
l’ensoleillement n’est pas suffisant et que l’eau dans le ballon n’est
pas suffisamment chaude, un autre système prend le relais pour
chauffer la mairie et l’école. Nous n’étudierons pas cette partie,
toutefois le système à développer devra lever une alarme lorsque
la température de sortie du ballon d’eau chaude n’est plus suffisante
pour le chauffage de la mairie et de l’école.
Le système est composé d’un chauffe eau solaire, d’un système de
stockage d’eau chaude composé d’un ballon de grosse capacité, de
moteurs de positionnement du chauffe eau, d’une pompe pour assurer
la circulation de l’eau, de capteurs de température, de capteurs de
passage d’eau minimum et maximum dans le ballon d’eau chaude.
Capteur Moteur Capteur
butée horizontal inclinaison température
chaud
Capteur
température
max
Capteur
butée vertical
Capteur
butée ouest Capteur
butée est
Moteur
orientation
Moteur
circulation
Vanne
remplissage
F IGURE 7. Vue simplifiée du système de chauffage d’eau à partir d’un
chauffe eau solaire.
Les conditions et modes de fonctionnement sont donnés ci-dessous.
– Pour être complètement efficace, le chauffe eau solaire doit
être positionné face au soleil du mieux possible. Pour cela, le
système devra piloter les moteurs de positionnement du chauffe
eau solaire.
– Le chauffe eau solaire s’oriente grâce à deux moteurs, l’un per-
met une orientation est-ouest, alors que l’autre permet d’orienter
l’inclinaison.
– Les deux axes de rotation sont équipés de butées, permettant de
définir des limites de rotation. Le moteur d’orientation dispose
des butées est et ouest positionnées façon à ce que le chauffe
eau soit face au soleil au levé et au coucher du soleil en plein été.
Ces butées sont équipées de capteurs indiquant que le système
est arrivé aux limites (capteurs est ouest représentés sur la
figure).
– Le moteur d’inclinaison dispose des butées dites
horizontale et verticale. Ces butées sont elles
aussi équipées de capteurs afin de détecter l’arrivée aux limites
(capteur horizontal vertical représentés sur la figure).
– Le système est équipé d’une pompe permettant de réaliser la
circulation d’eau depuis le ballon d’eau chaude vers le chauffe
eau.
– L’eau ne doit circuler que si la température de sortie du chauffe
eau solaire est plus élevée que la température de sortie du ballon
d’eau chaude.
– Il est toutefois interdit de poursuivre la circulation d’eau lorsque
la température d’eau chaude au sommet du ballon est supérieure
au maximum.
– Le ballon d’eau doit être maintenu entre les niveaux min et
max, et cela est à assurer par la commande de la vanne de
remplissage. Les passages de l’eau devant les capteurs min et
max provoquent des interruptions.
– Si le niveau d’eau dans le ballon d’eau descend en dessous
du capteur TropBas, alors une alarme doit être levée pour
indiquer un problème de remplissage du ballon. Dans ce cas, la
circulation d’eau dans le chauffe eau doit être interrompue.
– La vanne de vidage est pilotée par un autre système dont nous
n’avons pas connaissance.
– Lorsque la température de chauffage est insuffisante (inférieure
à Tchauf f age alors le système doit lever une alarme indiquant
qu’un autre système doit éventuellement prendre le relais pour
chauffer les bâtiments publics.
B. Second exemple de cahier des charges
Max
Min L’objectif de ce projet est de concevoir et de mettre en œuvre un
TropBas système de gestion de centrale à béton. L’obtention d’une toupie de
béton résulte du mélange de trois agrégats différents (A1, A2, A3),
Capteur
température de ciment (C1 ou C2) et d’eau. La centrale à béton, représentée à
chauffage
la figure 8, est composée des éléments suivants :
– Silos de stockage des agrégats (SA1 , SA2 , SA3 ) et des ciments
Capteur (SC1 , SC2 )
température
Vanne
froid
vidage
– Silos intermédiaires pour les agrégats et les ciments
– Balances BA et BC permettant de mesurer les quantités
d’agrégats et de ciments
– Tapis TA et TC permettant de transférer les agrégats et les
ciments vers le malaxeur
– Malaxeur équipé d’une vis sans fin permettant de mélanger les
différents éléments.
Le conducteur de la toupie, demande la réalisation d’un mélange
par l’intermédiaire d’un bouton Start après avoir indiqué le type de
béton, le volume souhaité et la distance à parcourir pour livrer cette
toupie. Chaque type de béton se caractérise par une composition
particulière en termes de quantité d’eau, d’agrégats et de ciment.
La composition de chaque type de béton est mémorisée au sein du
système de gestion. Les différents types utilisés sont définis dans la
partie suivante.
Chaque silo intermédiaire x d’agrégats et de ciment est équipé
de deux vannes tout ou rien Vx.1 et Vx.2 permettant de remplir et de
vider ce silo. De plus, chaque silo possède deux capteurs xmin et
xmax permettant de détecter par l’intermédiaire d’une interruption
si le niveau minimal et le niveau maximal sont atteints. Le système à
concevoir doit maintenir en permanence dans chaque silo le niveau
 Silos de stockage agrégats Silos de stockage des ciments et il est aussi l’occasion de clarifier la séparation entre l’étape de
Eau
SA1 SA2 SA3 SC1 SC2 réflexion de l’étape de codage. Nous insistons d’ailleurs fortement
sur le fait quel le travail de l’ingénieur s’achève à la modélisation et
la vérification de la solution, et qu’à ce stade c’est le technicien qui
prend le relai pour implémenter la solution modélisée.
VA1.1 VA2.1 VA3.1 VE1 VC1.1 VC2.1 Comme ce projet poursuit aussi l’objectif d’une confrontation à
Silos
MaxA3 un operating system temps réel, nous demandons ensuite aux
intermédiaires Silos étudiants de développer leur application de contrôle et de valdier
Nplus
agrégats intermédiaires celle-ci. La découpe de l’application en plusieurs parties permet
MinA3 SIC1 SIC2
SIA1 SIA2 SIA3 Nmoins ciments
aux étudiants de tester leur développement indépendamment et de
VA1.2 VA2.2 VA3.2 VC1.2 VC2.2
Balance C vérifier que celle-ci fonctionne, avant de faire l’assemblage total de
Balance A
la solution.
Pmoins, Pplus Pmoins, Pplus
VBA
Notons que pour aller plus loin, nous pourrions envisager de croiser
VE2 VBC
Tapis A Tapis C
les rapports de modélisation et de demander que chaque binôme
d’étudiants code la solution modélisée par un autre binôme. Pour
TPA éviter trop de tension lors du déroulement du projet, nous n’imposons
TPC
Malaxeur CMLX pas ce croisement des rapports.
VI. C ONCLUSION
VM Ayant constaté la difficulté de nos étudiants à comprendre l’intérêt
de la modélisation d’une solution avant le passage au code, nous
Camion
avons développé un outil de simulation de réseaux de Pétri, per-
mettant de sensibiliser les étudiants au fait que lorsqu’une solution
est correctement modélisée, elle peut être vérifiée/validée et qu’une
F IGURE 8. Synoptique de la centrale à béton fois cette validation effectuée, il ne reste alors plus qu’à développer
le code de cette application. La partie intelligente du travail est
contenue dans la définition de la solution, la partie codage est quant
entre ces valeurs minimales et maximales. à elle directement liée à la technologie et nécessite des compétences
de technologues précises et complètes, mais il n’y a normalement
... pas de remise en cause d’organisation générale de la solution à
De la même façon que sur l’exemple précédent, cette brève ce niveau : il s’agit en général simplement d’instancier la solution
présentation est suivi d’explications concernant les modes de fonc- sur une technologie donnée. Bien que ce passage au code puisse
tionnement attendus. nécessiter des compétences d’ingénieur, notamment pour être en
mesure de développer des solutions robustes et respectant l’ensemble
V. I MPACT DE L’ UTILISATION DE CET OUTIL des contraintes, nous souhaitons insister sur le fait qu’une partie
Si l’objectif global de ce projet est de confronter nos étudiants au importante du travail est fait lors de la modélisation et qu’il s’agit
développement de codes dits temps réel, ce projet poursuit plusieurs alors d’autres compétences qui sont mises en œuvre pour la suite du
objectifs, dont l’un qui consiste à leur faire prendre conscience de développement, et notamment des compétences faisant appel à des
l’importance de la modélisation. Mais il s’agit aussi de les confronter connaissances technologiques.
à un operating system du commerce qui a fait ses preuves et sur lequel Le passage obligé par une modélisation, ben qu’au départ mal vécu
ils pourraient être amené à travailler, à savoir VxWorks. par les étudiants, est au final vue comme un plus puisqu’il permet
L’obligation de produire une modélisation, bien qu’au départ mal de mieux cerner les différentes phases de développement : la phase
vécue par les étudiants, se révèle au final un guide très apprécié de réflexion et la phase de codage.
par les étudiants lors du passage au code. L’évaluation de cette Le meilleur critère permettant d’évaluer l’impact de ce projet et
modélisation est de plus une contrainte suffisamment importante pour de la méthode utilisée est très certainement la lecture des rapports
qu’ils jouent le jeu. Les étudiants appréhendent alors la difficulté de de stage de fin d’étude/stage d’ingénieur. En effet, dans ce stage, les
la modélisation. C’est un exercice difficile, dont ils ne comprennent élèves ingénieurs sont soumis aux méthodes de travail de l’entreprise
pas l’intérêt immédiat. et rare sont celles qui laisseront un étudiants se lancer dans une
Après avoir modélisé une solution, les étudiants sont à moitié phase de codage sans avoir validé une solution au préalable. À
convaincu de l’intérêt du travail qu’ils ont fournis, mais ils constatent la lecture de ces rapports, il n’est pas rare de voir apparaitre une
alors rapidement que leur modélisation est un support d’échange avec modélisation très proche, dans sa forme, de ce que les étudiants
l’enseignant et que l’on ne discute pas de problème de syntaxe d’un ont mis en œuvre dans ce projet. Au delà de la satisfaction de
langage mais bien de problème concernant la solution. voir son propre enseignement réutilisé directement dans l’entreprise,
Lorsque les étudiants passent au codage, ils parviennent la satisfaction est plutôt de voir que le futur ingénieur est alors
généralement à décomposer plus facilement le travail en binôme. maintenant probablement complètement convaincu de l’intérêt d’une
En effet, la modélisation fait systématiquement apparaitre des fonc- réflexion avant de se lancer dans le codage, contrat rempli ! ! !
tions différentes, et cette découpe permet d’identifier clairement les
dépendances et les interactions entre les fonctions.
Le passage par l’outil de simulation de réseaux de Pétri est
généralement très révélateur pour les étudiants. L’outil permet en
effet de faire le lien entre la modélisation et le système à piloter,

View publication stats