P13B11 Système de re-programmation multi processeur sur site » Historique » Version 12
Anonyme, 08/04/2021 09:32
1 | 1 | Anonyme | *Projet GE2-GE3 2013* : P13B11 Système de re-programmation multi processeur sur site |
---|---|---|---|
2 | *Entreprise / Client* : Cooper Safety, Jonathan BERNARD |
||
3 | *Auteurs* : Sébastien CAUX, Louis PESTEIL |
||
4 | *Responsable Projet* : Jacques LAFFONT |
||
5 | *Tuteur industriel* : Jean-Yves RIGNAULT |
||
6 | |||
7 | [[1. Résumé]] |
||
8 | [[2. Abstract]] |
||
9 | [[3. Introduction]] |
||
10 | [[4. Présentation du Sujet]] |
||
11 | [[5. Cahier des Charges]] |
||
12 | [[6. Developpement]] |
||
13 | |||
14 | p(((. [[1. CAN]] |
||
15 | [[2. Bootloader]] |
||
16 | [[3. IHM]] |
||
17 | |||
18 | [[7. Gestion de Projet]] |
||
19 | |||
20 | [[1. W.B.S.]] |
||
21 | [[2. Gantt]] |
||
22 | |||
23 | [[8. Notes d'application]] |
||
24 | |||
25 | p(((. [[1. Détail d'un protocole de reprogrammation d'un micro-controleur sur site]] |
||
26 | [[2. Mise en place d'une stratégie de reprogrammation. Sûreté de Fonctionnement]] |
||
27 | |||
28 | [[9. Bilan]] |
||
29 | |||
30 | p(((. [[1. Etat d'avancement]] |
||
31 | [[2. Analyse Critique]] |
||
32 | [[3. Perspectives]] |
||
33 | |||
34 | --- |
||
35 | |||
36 | h2<. Résumé |
||
37 | |||
38 | *Projet Polytech proposé par Cooper Safety dans le but de voir si la reprogrammation par bus CAN de leur produits chez leurs clients est possible, afin d'améliorer leur catalogue. |
||
39 | Il faudra réaliser un système multicartes / multiprocesseurs dialoguant entre elles via un bus CAN et dont la structure permet une reprogrammation de tous les microcontrôleurs à partir d’une interface PC/CAN par USB. |
||
40 | De plus il sera possible de reprogrammer chaque microcontrôleur de manière indépendante de telle manière que les autres microcontrôleurs continuent leur tâche en cours. |
||
41 | Un logiciel de supervision sur un ordinateur permettra de contrôler les taches en cours sur chaque microcontrôleur ainsi que leur version de logiciel embarqué.* |
||
42 | |||
43 | --- |
||
44 | |||
45 | h2<. Abstract |
||
46 | |||
47 | *Polytech Clermont-Ferrand project proposed by Eaton-Cooper Safety to know if a reprogramation of their products by CAN is possible in order to improve their catalog of products. |
||
48 | Creation of a multi-cards/processor system with a bus CAN communication which can reprogram any of the microcontroller of the system by an USB interface between a computer and the bus CAN. |
||
49 | In addition, it will be possible to reprogram each microcontroller independently such as the other microcontroller keep running their current task. |
||
50 | A supervision software on a laptop will enable to control the current task as the version of the software inside the different microcontroller of the system.* |
||
51 | |||
52 | --- |
||
53 | |||
54 | h2<. Introduction |
||
55 | |||
56 | *Dans le cadre de nos études en dernière année de cycle ingénieur à Polytech Clermont-Ferrand au sein du département génie électrique, nous avons un projet industriel de fin d’étude à mener. Dans notre cas, notre projet a été proposé par Cooper Safety basé à Riom. Le sujet concerne la reprogrammation de processeurs à distance, via un bus CAN. Actuellement, lors de la construction d’une nouvelle aile d’un bâtiment par exemple, Eaton se doit de proposer à son client un matériel fonctionnel, même après ces changements. Elle doit donc mettre à jour le dispositif d’alarme incendie. Un technicien doit venir sur place. Il doit prendre chaque carte électronique pour les remplacer par des versions provisoires. Il les ramène ensuite à l’usine pour les mettre à jour, puis revenir les replacer dans le bâtiment. Cela requiert beaucoup d’interventions chez le client, sans compter les allers-retours qui vont avec. Notre travail est de faire en sorte qu’il puisse mettre à jour tout le système directement en branchant un ordinateur par câble USB à la carte principale. Notre projet est donc un démonstrateur dans une optique d’amélioration de produit, de façon à réduire le coup et le temps d’intervention de mise à jour.* |
||
57 | |||
58 | h3<. Eaton-Cooper |
||
59 | |||
60 | *Eaton est une société de gestion d’alimentation fournissant des solutions éco énergétiques qui aident leurs clients gérer efficacement l’énergie électrique, hydraulique et mécanique. Eaton a acquis Cooper Industries en Novembre 2012. |
||
61 | Le chiffre d’affaires des sociétés combinées 2012 était de 21,8 milliards. Eaton compte environ 102 000 employés et vend ses produits à des clients dans plus de 175 pays. |
||
62 | Pour l’usine basée à Riom (avec laquelle nous travaillons), le chiffre d’affaire annuel est d’environ 58 millions d’euros pour un effectif de 220 personnes avec une fabrication de 500 000 unités par an. |
||
63 | C'est une entreprise qui créé des alarmes incendies.* |
||
64 | |||
65 | *Le système d’alarme incendie dans un bâtiment peut être très complexe. Dans de grands bâtiments type entreprises, hôpitaux ou écoles, il peut être extrêmement sophistiqué. La stratégie d’évacuation d’un bâtiment est étudiée avec une grande précision afin d’être la plus adéquate. Selon l’endroit où est déclaré le feu, les portes coupe-feu à fermer, les systèmes de ventilation de fumée à mettre en route et les sirènes à faire sonner sont différents. Un système ressemblant à un ordinateur central, la carte principale, gère ces scénarios en étant connecté aux différents éléments du bâtiment.* |
||
66 | |||
67 | 2 | Anonyme | p=. !https://forge.clermont-universite.fr/attachments/download/16273/cooper_20140121171243_20140121171254.jpg! |
68 | |||
69 | 3 | Anonyme | p=. !https://forge.clermont-universite.fr/attachments/download/16274/systeme_cooper_20140121171407_20140121171610.png! |
70 | |||
71 | *Les cartes électroniques sont disposées dans le boitier principal. Ces cartes peuvent être des cartes de boucles, des cartes d’alimentation et la carte principale. |
||
72 | Les cartes de boucles sont connectées aux boîtiers de déclenchement manuel ou aux détecteurs de fumées. |
||
73 | Les cartes d’alimentation approvisionnent en énergie les alarmes sonores et visuelles.* |
||
74 | |||
75 | h2<. Présentation du Sujet |
||
76 | *Dans un système d'alarme incendie, plusieurs cartes électroniques sont stockées dans un panneau. Lors d'une mise à jour du système, il est pour l'instant nécessaire de venir changer les cartes avec des versions temporaires afin de les reprogrammer. Nous devons créer des programmes à implanter sur les différentes cartes du système, pour que la carte principale soit capable de reprogrammer toute les autres cartes par bus CAN, depuis une interface d'un PC branché par USB à cette même carte.* |
||
77 | |||
78 | *L'utilisateur choisi la carte à reprogrammer et la version du programme sur le PC. |
||
79 | Le PC envoie le nouveau programme par bus USB à la carte principale. |
||
80 | La carte principale envoie ensuite le programme à la carte choisie par bus CAN.* |
||
81 | |||
82 | 4 | Anonyme | p=. !https://forge.clermont-universite.fr/attachments/download/16275/reprog2_20140121171827_20140121171941.png! |
83 | |||
84 | *A chaque trame, la carte cible envoie un acknowledge ainsi qu'en toute fin de transmission. |
||
85 | Le processeur est maintenant reprogrammé, la carte principale envoie la confirmation au PC par USB.* |
||
86 | |||
87 | *+La confirmation s'affiche sur l'IHM et l'utilisateur peut lancer une nouvelle reprogrammation+* |
||
88 | |||
89 | 5 | Anonyme | p=. !https://forge.clermont-universite.fr/attachments/download/16276/ihm_20140121201128_20140121201243.PNG! |
90 | |||
91 | --- |
||
92 | |||
93 | h2<. Cahier des Charges |
||
94 | |||
95 | p(((. *Le travail à fournir est un ensemble de programme, afin de permettre la reprogrammation de plusieurs familles de microcontrôleurs, la famille PIC18FXXK80 et la famille DSPIC33EP de chez Microchip, et la famille RX62T de chez Renesas. Pour ceci, doit être créé : la communication en bus CAN, entre ses 3 familles de cartes, et la carte principale composée d’un microcontrôleur PIC32. Ainsi que la communication bus USB, entre le PC et la carte PIC32, de même que l’IHM. Les 3 cartes filles (PIC18F, DSPIC et RX62T) doivent pouvoir se reprogrammer depuis l’interface CAN avec une grande sécurité de transmission.* |
||
96 | |||
97 | --- |
||
98 | |||
99 | h2<. Développement |
||
100 | |||
101 | h2<. Advanced Reprogram & Communication by CAN |
||
102 | |||
103 | * |
||
104 | L’ARCCAN est la bibliothèque utilisateur que nous avons créé durant notre projet. Cette bibliothèque contient 2 modules, un servant à la communication, et l’autre à la reprogrammation des microcontrôleurs. |
||
105 | Il y a 2 modules principaux dans l’ARCCAN, le module de communication et le module de reprogrammation.* |
||
106 | |||
107 | h2<. CAN |
||
108 | |||
109 | p(((. * |
||
110 | La communication dans l’ARCCAN est donc faite par bus CAN. Le bus CAN est un bus asynchrone et multi-maitres. Son débit max est de 1 Mbits/s. Les trames CAN sont repérées par les microcontrôleurs sur le bus par leur identifiants. Nous utilisons le CAN 2.0B, les identifiants utilisés ont donc une taille de 29 bits. Une trame CAN peut contenir jusqu’à 8 octet de données utiles. La sécurité de transmission est assurée pour chaque trame grâce à un code CRC au sein même de la trame.* |
||
111 | |||
112 | 6 | Anonyme | p=. !https://forge.clermont-universite.fr/attachments/download/16277/trame_20140121191421_20140121191526.PNG! |
113 | |||
114 | *Le protocole CAN fonctionne donc grâce à des « boîtes aux lettres » qui réagissent ou non à différents identifiants de trames. |
||
115 | Pour l’ARCCAN, nous avons défini un identifiant normalisé (sur 29 bits) qui convient à nos besoins et ceux du client.* |
||
116 | |||
117 | p(((. *Identifiant des trames CAN :* |
||
118 | |||
119 | 7 | Anonyme | p=. !https://forge.clermont-universite.fr/attachments/download/16278/ident_20130512192712_20130512193152.PNG! |
120 | |||
121 | *Ainsi, l’identifiant contient l’adresse de la carte cible (classe de carte + numéro de carte) ainsi que l’instruction de ce qu’elle doit faire (protocole + commande). La classe de carte représente le type de carte, cela permet de classer les différentes cartes du système dans une logique de réseau fonctionnel. Le protocole indique ce que l’on est en train de faire (communication, reprogrammation . . . ) et la commande précise ce qui est demandé à la carte (changer une valeur de consigne, renvoyer une valeur de tel capteur, effectuer un redémarrage, changer le programme du segment A, redémarrer sur un autre segment de programme...).* |
||
122 | |||
123 | p(((. *L'architecture du réseau de carte est donc celui ci :* |
||
124 | |||
125 | 8 | Anonyme | p=. !https://forge.clermont-universite.fr/attachments/download/16279/archi_20130512192509_20130512192706.PNG! |
126 | |||
127 | p(((. *2 protocoles utilisés : échange de données et bootloader (reste 14 possibilités d'extension)* |
||
128 | |||
129 | *La sécurité de transmission sera faite par CRC : sur chaque trame et sur la totalité du bootloader.* |
||
130 | |||
131 | *La transmission CAN est fonctionnelle pour les différentes marques et familles de cartes que nous utilisons.* |
||
132 | |||
133 | h2<. Bootloader |
||
134 | |||
135 | p(((. *Le projet est dans un cadre de sécurité de fonctionnement très importante, le bootloader avec un seul segment n’est donc pas la solution retenue. Après discutions avec le client , l’implantation choisie est la répartition émoire partagée avec 2 segments programmables. |
||
136 | Voici l’implantation réalisée pendant le projet :* |
||
137 | |||
138 | 9 | Anonyme | p=. !https://forge.clermont-universite.fr/attachments/download/16280/boot1_20140123131658_20140123131758.PNG! |
139 | |||
140 | p(((. *2 versions du firmware avec possibilité de redémarrer sur le firmware précédent. |
||
141 | La carte bloquée pendant la mise à jour.* |
||
142 | |||
143 | *Le bootloader est donc lancé au démarrage de la carte, et doit donc choisir de lancer le programme ou de passer en mode bootloader (le mode de reprogrammation) :* |
||
144 | |||
145 | 10 | Anonyme | p=. !https://forge.clermont-universite.fr/attachments/download/16281/fsm_20140123132013_20140123132025.PNG! |
146 | |||
147 | *Détail du fonctionnement du mode bootloader :* |
||
148 | |||
149 | 11 | Anonyme | p=. !https://forge.clermont-universite.fr/attachments/download/16282/fsm2_20140123132200_20140123132211.PNG! |
150 | |||
151 | h2<. IHM |
||
152 | |||
153 | h2<. L'Interface Homme Machine est réalisée en Qt. |
||
154 | Fonctionnalités de l'IHM: |
||
155 | |||
156 | p(((. - Liste des cartes |
||
157 | - État des cartes |
||
158 | - Versions des firmwares implentés |
||
159 | - Choix de démarrage |
||
160 | - Envoi de nouveaux firmwares |
||
161 | - Changement du numéro de carte |
||
162 | |||
163 | 12 | Anonyme | p=. !https://forge.clermont-universite.fr/attachments/download/16283/ihm_20140121201128_20140121201243.PNG! |
164 | |||
165 | --- |
||
166 | |||
167 | h2<. Gestion de Projet |
||
168 | |||
169 | W.B.S |
||
170 | |||
171 | 1 | Anonyme | p=. !! |