Etude de CAS- Majeure Systèmes Embarqués

Etude d'un système de contrôle réparti

Présentation

• des procédés réels à commander,
• leurs interfaces électroniques,
• éventuellement des procédés simulés à commander,
• plusieurs processeurs assurant différentes fonctionnalités (acquisition, conversion de commande, contrôleur, IHM, journal de trace ...),
• des réseaux de communication entre ces processeurs.

Procédé

• 2 pendules inverses coordonnés (physique),
• 2 moteurs coordonnés (physique), soit reliés physiquement (laminoir ou chaîne de transmission),
• amortisseurs commandés (2ème ordre simulé)
• ...

• 2 pendules à contrôler en position x géographiquement distants,
• 1 générateur de consigne en position géographiquement distant,
• 1 visualisation déportée des états des éléments du système.
  

Déroulement

1. Présentation - R.KOCIK   transparents de la présentation
   

2. Synthèse de contrôleurs - A.CELA

• Modélisation des procédés
• Définition et synthèse de contrôleurs
• Définition des intervalles possibles d'échantillonnage et de retards.
• Définition des critères de qualité
• Simulation d'une implantation distribuée

3. Implantation mono-processeur - R.HAMOUCHE, R.KOCIK

• Prise en main de l'architecture matérielle et de l'architecture logicielle
  
• Développement de drivers d'E/S
• Implantation temps réel des lois de commandes
• Tests et validation avec le procédé

4. Extension multi-processeurs - R.HAMOUCHE, R.KOCIK

• Découpage de la loi de commande
• Développement de drivers de communication
• Implantation distribuée temps réel
• Tests et validation avec le procédé
• Intégration du controle du deuxième procédé

5. Comparaison avec les simulations - A.CELA

• Prise en compte, dans les simulations, des caractéristiques de l'implantation réalisée
  
• Comparaison avec les simulation réalisées en 2)
• Comparaison avec le comportement réel
• Conclusion
  

6. Soutenance - A.CELA, R. HAMOUCHE, R.KOCIK
   

Quelques conseils

• Avant de vous précipiter à l'écriture de vos modules, lisez les documentations fournies, le temps "perdu" au départ sera largement récupéré ensuite.
• Développez vos applications de façon modulaire : un module de gestion des E/S, un module gestion CAN, un module application. Ainsi la correction d'un bug sur un module profitera à l'ensemble des applications utilisant ce module.
  
• Soyez curieux et posez vous des questions : comment marche la carte ? quelle est la bande passante des convertisseurs A/D?, comment pourra-t-on la connecter au pendule ? quels sont les avantages et inconvénients des différentes solutions techniques enviseagables ?...
• Prenez le temps d'écrire un code propre en utilisant entre autres le "#define".
• Notez au fur et à mesure les problèmes rencontrés, les remarques et solutions apportées, il vous sera plus facile par la suite de rédiger votre rapport.
• Gardez à l'esprit qu'il est plus facile de résoudre les problèmes un par un plutôt que tous en même temps : avancez par étapes en séparant bien les problèmes. Garder vos programmes de test qui vous ont permis de valider chacunes de ces étapes. En cas de problème , vous pourrez ainsi vérifier facilement si le matériel est défectueux où si ce sont les modifications apportées à votre code qui sont la cause de votre nouveau bug.
• Progressez pas à pas, en validant très régulièrement.
• Gardez les versions intermédiaires validées de vos programmes.
  
• Rédigez votre rapport au fur et à mesure.
  
• N'hésitez pas à poser des questions.
• Tirez parti du fait que vous êtes en binome : partagez-vous le travail pour plus d'efficacité.
• Le matériel mis à votre disposition est couteux et fragile, prennez en soin :
• NE DEMONTEZ PAS LES KITS
• ne faites pas de branchement sous tension
• évitez les débranchements et rebranchements répétés
• validez toujours le comportement de votre application (allure et cohérence des signaux) avant d'allumer l'ampli de puissance qui contrôle le moteur du pendule
• rangez correctement le matériel en fin de séance, laissez la salle correctement rangée

Annexes

Architecture Matérielle

Architecture Matérielle

• Station de développement : elle est composée d'un PC de bureau relié à une connexion Ethernet. L'environnement de travail est Linux RTAI 4. Il dispose d'une carte de communication CAN ADLINK 7841 PCI. 
  

• PC embarqué : C'est une carte ARCOM SBCGX533 qui dispose d'une connexion Ethernet, mais ni écran ni clavier. L'OS installé sur la carte est Linux RTAI 3.4.  Les programmes seront développés et compilés sur la station de travail et téléchargés sur la carte via la connexion ethernet. Une carte AIM104 CAN est connectée à cette carte.
  

• carte communication CAN ADLINK 7841 PCI
• Cette carte intègre 2 SJA1000 afin de fournir 2 connexions CAN indépendantes.
  
• Identification de la carte sur le bus PCI : VENDOR_ID = 0x144A,  DEVICE_ID = 0x7841
  
• Vitesse de transmission :  125Kb/s, Determination of bit timing parameters SJA1000_BT.ps
• manuelPCI7841.pdf
• Data Sheet SJA1000.pdf
• squelette rtai gestion pci squelette_can_pci_linux.c

• carte communication CAN AIMPC104

• Cette carte intègre 1 SJA1000.
  
• Cette carte connectée au bus PC104 de la carte embarquée est directement mappée dans la mémoire I/O de la carte ARCOMGX533. Le SJA1000 est accessible à l'adresse 0x180 et génère des intérruptions sur l'IRQ 5
  
• Vitesse de transmission :  125Kb/s, determination of bit timing parameters SJA1000_BT.ps
• manuelAIM104.pdf
• Data Sheet SJA1000.pdf

• carte Acquisiton ADC : ADVANTECH 3718HG PC104

• La carte est configurée avec l'adresse de base 0x320
  

• PCM-3718H.pdf
• configuration des jumpers :
• Base Address Switch Setting SW1

• DMA channel &timer clock JP1:  1M, DM3   
• Channel config JP2 : 16 S.E. inputs
• External input or DIO JP3 : DIO 0       

• carte Acquisiton DAC : ADVANTECH  PCM-3712 PC104
• La carte est configurée avec l'adresse de base 0x300
  
• PCM-3712.pdf
• configuration des jumpers
•   Base Address Switch Setting SW1
             1 2  3 4 5  6 7 8
        on        X X X X X X
        off X X    
• JP11: Asynchronous mode
• Channel 1 (JP1,JP3,JP5) : bipolar +-10v
• Channel 2 (JP2,JP4,JP10) : bipolar +-10V
  

Architecture logicielle

• RTAI 3.4. (carte PC embarqué) :
• Le nom de réseau de la carte  est arcom#@esiee.fr  ou # est le numéro inscrit sur le connecteur ethernet de la carte.
  
• Makefile34 pour compiler sur la station un module pour RTAI 3.4, il peut aussi être utilisé pour envoyer les modules compilés sur la cible.
  
•  transfert de fichiers entre la machine développement et le PC embarqué :  
• scp fichier_a_transferer arcom@nom_machine.esiee.fr:/home/arcom
• il est possible de se logger à distance sur la carte embarquée :
• ouvrir une fenêtre console
• ssh arcom@nom_machine.esiee.fr
• login : arcom password arcom,
• le chargement des modules peut se faire classiquement avec la commande insmod ou à l'aide du script runarcom

• RTAI 4 (station de développment)
• login: rtai password: rtai
  
• la documentation est disponible sous forme html sur votre machine : voir menu "esiee" de la machine
  
•  Makefile4 pour compiler un module RTAI 4
  
• le chargement des modules peut se faire à l'aide du script runPC
• Le compte RTAI étant utilisé par tout le monde, archivez vos sources sur votre compte à la fin de chaque séance. Utilisez pour cela la commande : scp fichier mon_login@acme1.esiee.fr:~mon_login/  
• Fichier archive :
  
• créer un fichier archive : tar -zcvf nom_fichier.tgz repertoire_a_archiver/
• décompresser un fichier archive : tar -zxvf fichier.tgz
  

Fichiers Fournis

• répertoire PC/
•  squelette_7841.c: Ce fichier est la base de votre module de communication CAN, a vous de le completer.
  
• Makefile4: ce makefile est à utiliser si vous voulez compiler un module pour RTAI 4. Il doit être édité :
• obj-m := module1_a_compiler.o module2_a_compiler.o ...
• Pour compiler vous pouvez utiliser la commande : make -f Makefile4
• runPC : chargement et déchargement des modules sur le poste de développement.
• ./runPC mon_module  chargera les principaux modules rtai et le module mon_module.ko

• répertoire test_can_7841/ : ce répertoire contient les modules pré-compilés de gestion de la carte can 7841 afin de vous permettre, en cas de doute, de vérifier que la carte CAN fonctionne correctement et est bien reliée au bus CAN. Ces modules utilisent le CAN à 125Kb/s.
• ./runtest test_CAN_recv lancera les modules de test pour la réception. La commande dmesg vous permettra de visualiser les informations sur les messages reçus.
• ./runtest test_CAN_send lancera les modules de test pour l'envoi. Une trame CAN est envoyée périodiquement. 

• répertoire ARCOMGX533/ 
  
• Makefile34 : ce makefile est a utiliser si vous voulez compiler un module pour RTAI 3.4 (carte ARCOM GX533).
  
• Il doit être édité :
  
• KIT = arcom#@esiee.fr  : remplacez le # par le numéro de la carte.
• obj-m := module1_a_compiler.o module2_a_compiler.o ...: spécifie la liste des modules à compiler.
  
• Pour compiler il vaut mieux le renommer en Makefile et lancer la commande: make
  
• Pour envoyer les modules compilés sur la carte ARCOMGX533 : make send
• Pour supprimer les modules compilés : make clean
  
• runarcom : script permettant de charger et décharger les modules sous RTAI 3.4 : ./runarcom mon_module_a_charger (Cette commande est à exécuter sur le PC embarqué).
  
• 3712.h : fichier header gestion de la carte conversion numérique/analogique 3712
• 3712.ko: module gestion carte conversion numérique/analogique 3712
• squelette_tp2.c : squelette du tp2
• répertoire test_CAN_AIM104/: ce répertoire contient les modules pré-compilés de gestion de la carte can AIMCANPC104 afin de vous permettre, en cas de doute, de vérifier que la carte CAN fonctionne correctement et est bien reliée au bus CAN. Ces modules utilisent le CAN à 125Kb/s. L'ensemble de ces fichiers doit être copié sur la carte ARCOMGX533. Les commandes suivantes pourront alors être exécutées sur la carte ARCOMGX533. 
• ./runtestarcom test_aim104can_recv lancera les modules de test pour la réception. La commande dmesg vous permettra de visualiser les informations sur les messages reçus.
• ./runtestarcom test_aim104can_send lancera les modules de test pour l'envoi. Une trame CAN est envoyée périodiquement. 

Format des drivers des carte d'acquisition

• Module RTAI pour la carte acquisition ADC. Ce module fournira les fonctions suivantes:
  

• int init3718(void) : initialisation de la carte d'acquisition. Cette fonction sera appelée dans l'init_module de 3718.o.  Retourne un entier nul lorsque l'initialisation est correcte.
• void SetChanel(int in_channel) : Cette fonction doit positionner le numéro de canal in_channel sur lequel devra être réalisée une conversion  Analogique-Numérique.
• void ADRangeSelect(int channel, int range) : sélectionne  la sensibilité (range) du canal channel
  
• u16 ReadAD(void) : réalise la conversion Analogique-Numérique sur le canal courant et retourne la valeur convertie.

• Module RTAI pour la carte acquisition DAC. Ce module fournira les fonctions suivantes:
• int init3712(void) : initialisation de la carte d'acquisition. Cette fonction sera appelée dans l'init_module.  Retourne un entier nul lorsque l'initialisation est correcte.
• void SetDA(int channel, int value) : Cette fonction doit positionner la valeur value dans le CNA de la sortie channel de la carte

Quelques outils et documents complémentaires :

• Xgraph un outil intéressant permettant de tracer des courbes 2D à partir de données sauvegardées dans des fichiers  : http://www.xgraph.org/
• Savoir documenter son code: http://ymettier.free.fr/articles_lmag/lmag33/lmag33.html
• Ecriture de drivers sous Linux : Linux_device_driver.pdf , le chapitre 15 est notemment consacré au fonctionnement du bus PCI
  

Rapport

BON COURAGE !!