Projet Modélisme ferroviaire du futur

CAHIER DES CHARGES FONCTIONNEL
Projet
Modélisme ferroviaire du futur
Maquette de train automatique sans liaison physique
Auteur : S. Abdellatif, P. Acco, P.-E. Hladik
Date : Décembre 2010
Version : 1.0
1. PRESENTATION GENERALE DU PROBLEME
1.1. FINALITE DU PROJET
L’INSA souhaite développer une maquette de train électrique révolutionnaire avec des voitures sans
liaisons mécaniques.
L’enjeu est immense : valorisation de sa formation d’ingénieur dans le domaine des systèmes
embarqués, développement des jouets du futur et démonstration pour les journées porte ouverte.
1.2. CONTEXTE
L'INSA de Toulouse, Institut National des Sciences Appliquées est une grande école publique
d'ingénieur en 5 ans qui diplôme environ 500 ingénieurs par an, dans 10 spécialités, allant de
l'informatique au génie civil en passant par les nanotechnologies et l'environnement.
Au sein de cet établissement, le département Génie Electrique et Informatique (GEI) a pour objectif
de former des ingénieurs pluridisciplinaires dans le domaine des sciences et technologies de
l’information, avec des approfondissements en Electronique, Automatique, Informatique
et Réseaux.
1.2.1. ÉTUDES DEJA EFFECTUEES
L’architecture matérielle de la plate-forme a été conçue et testée. Chaque voiture de la maquette
possède son propre calculateur et est reliée aux autres par un bus CAN afin d’échanger les
informations entres voitures.
Un ensemble de composants logiciels unitaires a aussi été développé pour cette plate-forme afin
d’en valider la faisabilité.
1.2.2. NATURE DES PRESTATIONS DEMANDEES
Les prestations demandées concernent d’une part la mise au point de la commande du moteur de
chaque voiture de manière à éviter les collisions et à poursuivre une trajectoire permettant de relier
les différentes stations dans les temps impartis.
Les prestations devront aussi conduire au développement logiciel de la plate-forme de contrôle en
passant par une étape de conception et d’implémentation.
De plus, une attention particulière est demandée au niveau de la mise en valeur du travail effectué
en particulier à travers des propositions d’amélioration pour la plate-forme.
2. ENVIRONNEMENT DU PRODUIT RECHERCHE
2.1. VUE GENERALE DU PRODUIT
La figure 1 représente l’architecture générale du système. Chaque voiture possède son propre
calculateur Cortex-M3 (carte Olimex STM32-H103) qui est reliée aux autres par un bus CAN
commun. Un calculateur au sol est aussi relié au bus CAN.
Figure 1 — Architecture de la plate-forme
2.2. CARACTERISTIQUES POUR CHAQUE ELEMENT
2.2.1. ACTIONNEUR
Le moteur est commandé par une régulation en modulant le courant.
Le cortex-m3 envoie une consigne de courant au format PWM à la carte de régulation de courant :
-
Un rapport cyclique de 0% correspond à un courant négatif maximal
-
Un rapport cyclique de 100% correspond à un courant maximal
-
Un rapport cyclique de 5O% commande un courant nul.
Une librairie de contrôle a été développée pour imposer ces différents niveaux de courant.
2.2.2. CAPTEUR DE POSITION
La position est mesurée à l’aide de codeurs incrémentaux. Il s’agit de capteurs optiques fixes
détectant la présence d’une bande blanche sur l’axe du moteur. Ces capteurs génèrent des fronts qui
sont décalés lorsque les roues tournent. Ils sont capturés par l’unité capcom du cortex-m3 et
incrémentent ou décrémentent un compteur. On obtient ainsi une mesure de la position de la roue
relative à la position initiale.
Un pilote est fourni pour gérer l’unité capcom et le capteur de position.
2.2.3. COMMUNICATION BUS CAN
La communication est assurée par une liaison physique par un bus CAN. Les messages échangés
sont spécifiés en annexe.
Une ébauche de librairie pour gérer la communication a été produite et permet l’échange de
messages.
2.2.4. COMMUNICATION XBEE
Chaque voiture possède une carte Xbee utilisée comme uart. Chaque carte est appareillée à un
boîtier unique de communication à connecter à un PC.
L’émission d’un message depuis une voiture se fait par l’appel à la fonction printf qui est
redirigée automatiquement sur l’uart.
2.2.5. GENERATEUR DE TRAJECTOIRE
Les voitures devant suivre une trajectoire afin d’assurer une accélération raisonnable, un générateur
a été produit à cet effet (voir document en annexe).
2. EXPRESSION FONCTIONNELLE DU BESOIN
2.3. FONCTIONS DE SERVICE
L’objectif est de concevoir et développer la commande et l’architecture logicielle de la plate-forme.
Les fonctions attendues sont :
-
Contrôler et commander les voitures sans liaison physique.
-
Assurer la sécurité des voitures.
-
Superviser le déplacement des voitures (envoi des trajectoires, signalisation des incidents,
communication de l’arrêt et du démarrage, etc.)
L’ajout de fonctions est encouragé et est aussi l’un des objectifs.
2.4. CRITERES D’APPRECIATION
La réalisation sera évaluée suivant les objectifs à atteindre. Pour chaque fonction, il est attendu une
conception solide et pour laquelle la preuve du bon fonctionnement est faite.
Le développement devra suivre des critères de qualité logicielle en particulier en ce qui concerne la
lisibilité et la maintenabilité.
Des propositions réalistes de nouvelles fonctionnalités et l’étude de leur faisabilité seront aussi un
critère pour évaluer la pertinence des réponses apportées.
3. CADRE DE REPONSE
Une présentation de 30 minutes en anglais en présence d’experts et ainsi que de néophytes.