Projet GE2-GE3 2013 : P13B11 Système de re-programmation multi processeur sur site
Entreprise / Client : Cooper Safety, Jonathan BERNARD
Auteurs : Sébastien CAUX, Louis PESTEIL
Responsable Projet : Jacques LAFFONT
Tuteur industriel : Jean-Yves RIGNAULT

1. Résumé
2. Abstract
3. Introduction
4. Présentation du Sujet
5. Cahier des Charges
6. Developpement

1. CAN
2. Bootloader
3. IHM

7. Gestion de Projet

1. W.B.S.
2. Gantt

8. Notes d'application

1. Détail d'un protocole de reprogrammation d'un micro-controleur sur site
2. Mise en place d'une stratégie de reprogrammation. Sûreté de Fonctionnement

9. Bilan

1. Etat d'avancement
2. Analyse Critique
3. Perspectives


Résumé

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.
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.
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.
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é.


Abstract

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.
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.
In addition, it will be possible to reprogram each microcontroller independently such as the other microcontroller keep running their current task.
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.


Introduction

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.

Eaton-Cooper

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.
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.
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.
C'est une entreprise qui créé des alarmes incendies.

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.

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.
Les cartes de boucles sont connectées aux boîtiers de déclenchement manuel ou aux détecteurs de fumées.
Les cartes d’alimentation approvisionnent en énergie les alarmes sonores et visuelles.

Présentation du Sujet
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.

L'utilisateur choisi la carte à reprogrammer et la version du programme sur le PC.
Le PC envoie le nouveau programme par bus USB à la carte principale.
La carte principale envoie ensuite le programme à la carte choisie par bus CAN.

A chaque trame, la carte cible envoie un acknowledge ainsi qu'en toute fin de transmission.
Le processeur est maintenant reprogrammé, la carte principale envoie la confirmation au PC par USB.

La confirmation s'affiche sur l'IHM et l'utilisateur peut lancer une nouvelle reprogrammation


Cahier des Charges

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.


Développement

Advanced Reprogram & Communication by CAN


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.
Il y a 2 modules principaux dans l’ARCCAN, le module de communication et le module de reprogrammation.

CAN


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.

Le protocole CAN fonctionne donc grâce à des « boîtes aux lettres » qui réagissent ou non à différents identifiants de trames.
Pour l’ARCCAN, nous avons défini un identifiant normalisé (sur 29 bits) qui convient à nos besoins et ceux du client.

Identifiant des trames CAN :

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...).

L'architecture du réseau de carte est donc celui ci :

2 protocoles utilisés : échange de données et bootloader (reste 14 possibilités d'extension)

La sécurité de transmission sera faite par CRC : sur chaque trame et sur la totalité du bootloader.

La transmission CAN est fonctionnelle pour les différentes marques et familles de cartes que nous utilisons.

Bootloader

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.
Voici l’implantation réalisée pendant le projet :

2 versions du firmware avec possibilité de redémarrer sur le firmware précédent.
La carte bloquée pendant la mise à jour.

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) :

Détail du fonctionnement du mode bootloader :

IHM

L'Interface Homme Machine est réalisée en Qt.
Fonctionnalités de l'IHM:

- Liste des cartes
- État des cartes
- Versions des firmwares implentés
- Choix de démarrage
- Envoi de nouveaux firmwares
- Changement du numéro de carte


Gestion de Projet

W.B.S

Gantt


Notes d'application

CAUX SEBASTIEN : Détail d'un protocole de reprogrammation d'un micro-controleur sur site

Détail d'un protocole de reprogrammation d'un micro-controleur sur site.pdf?

PESTEIL LOUIS : Mise en place d'une stratégie de reprogrammation. Sûreté de Fonctionnement

Mise en place d'une stratégie de reprogrammation. Sûreté de Fonctionnement.pdf?


Bilan

Etat d'avancement

La partie Renesas n’a pas pu aboutir dans les temps, la partie communication par CAN est bien fonctionnelle, ainsi que les entrées-sorties du microcontrôleur, le bootloader en lui-même n’est pas fonctionnel. Nous avons un problème au niveau de l’écriture dans la ROM, ce problème n’a pas pu être résolu à temps. Nous avons sollicité une explication plus détaillée de la datasheet correspondant à l’écriture en ROM d’un salarié de Renesas connu de Polytech Clermont-Ferrand, mais nous n’avons obtenu aucune réponse de sa part.

La partie Microchip du rapport était la plus importante, puisque c’était la priorité denotre client.
Cette partie du projet était complète, allant de la réalisation du schéma des cartes jusqu’à la programmation de leur microcontrôleur. Nous avons donc d’abord élaboré le schéma de la carte PIC18FXXK80. Puis fait le routage de cette même carte. Cela a été fait en priorité car la suite de notre travail ne pouvait vraiment commencé que cette carte créée.

La carte DSPIC, elle, a été réalisée par la sous-traitance des GE4, nous leur avons fourni le schéma électrique de la carte , et ils l’ont routé eux même.

Le codage de la communication CAN du PIC18F a été fait en 1er , pendant la sous-traitance de l’autre carte. Puis ensuite, le codage du bus CAN pour le DsPIC33EP?. Lorsque toute la chaine de communication était pérationnelle, le codage du bootloader sur cible PIC18FXXK80 a été fait.

Analyse Critique

L’ensemble du projet n’a pas pu être finalisé dans les temps. En effet, la partie reprogrammation ne fonctionne pas sur les cartes DSPIC, et sur le RX62T.
Les cartes avec microprocesseur microchip ont été créée et sont fonctionnelle en entrée/sorties.
La partie communication par bus CAN fonctionne sur toutes les plateformes demandées (cartes DSPIC, PIC18FXXK80 et RX62T).
L’interface homme machine est elle aussi terminée.
La communication USB entre le PC et la carte PIC32 fonctionne également.
La reprogrammation sur le PIC18FXXK80 est fonctionnelle, c’est ce qui intéressait en priorité notre client, puisque Eaton-Cooper Riom travaille uniquement sur cible Microchip, sur des cibles PIC.

Perspectives

Il est possible avec plus de temps de finir le projet, le bootloader des micro-controleurs DsPic33EP? et RX62T. Il est aussi possible de voir avec d'autres familles et même d'autres fabricants (ARM).
Il est possible aussi de travailler avec d'autres bus que le bus CAN, en designant un bus propriétaire par exemple.

cooper_20140121171243_20140121171254.jpg (26 KB) axel BARRIEUX, 04/08/2021 09:21 AM

systeme_cooper_20140121171407_20140121171610.png (103 KB) axel BARRIEUX, 04/08/2021 09:22 AM

reprog2_20140121171827_20140121171941.png (223 KB) axel BARRIEUX, 04/08/2021 09:23 AM

ihm_20140121201128_20140121201243.PNG (18.7 KB) axel BARRIEUX, 04/08/2021 09:24 AM

trame_20140121191421_20140121191526.PNG (35.9 KB) axel BARRIEUX, 04/08/2021 09:26 AM

ident_20130512192712_20130512193152.PNG (14.9 KB) axel BARRIEUX, 04/08/2021 09:26 AM

archi_20130512192509_20130512192706.PNG (35.7 KB) axel BARRIEUX, 04/08/2021 09:27 AM

boot1_20140123131658_20140123131758.PNG (16.3 KB) axel BARRIEUX, 04/08/2021 09:28 AM

fsm_20140123132013_20140123132025.PNG (35.6 KB) axel BARRIEUX, 04/08/2021 09:29 AM

fsm2_20140123132200_20140123132211.PNG (56.9 KB) axel BARRIEUX, 04/08/2021 09:29 AM

ihm_20140121201128_20140121201243.PNG (18.7 KB) axel BARRIEUX, 04/08/2021 09:31 AM

wbs_reprog_20130512180257_20130512180430.png (135 KB) axel BARRIEUX, 04/08/2021 09:32 AM

Gantt1_20130411090300_20130512175728.PNG (21.5 KB) axel BARRIEUX, 04/08/2021 09:33 AM

Gantt2_20130512175828_20130512175908.PNG (10.7 KB) axel BARRIEUX, 04/08/2021 09:33 AM

renesas_20140121191104_20140121191131.jpg (59.5 KB) axel BARRIEUX, 04/08/2021 09:36 AM

pic18f_20140121191837_20140121191854.jpg (27.6 KB) axel BARRIEUX, 04/08/2021 09:38 AM

dspic_20140121191837_20140121191904.jpg (26.9 KB) axel BARRIEUX, 04/08/2021 09:38 AM