IMA4 2018/2019 P57 : Différence entre versions

De Wiki de Projets IMA
(Semaine 2)
(Réalisation du Projet)
Ligne 210 : Ligne 210 :
 
La fonction OTABoot devra pouvoir stocker temporairement dans la mémoire (RAM ou Flash) les données reçu jusqu'à la fin de la réception et vérifier la conformité des données reçu avant de flasher l'espace mémoire.
 
La fonction OTABoot devra pouvoir stocker temporairement dans la mémoire (RAM ou Flash) les données reçu jusqu'à la fin de la réception et vérifier la conformité des données reçu avant de flasher l'espace mémoire.
  
==Semaine 3==
+
==Semaine 3 à 7==
==Semaine 4==
+
Conception du circuit électronique
==Semaine 5==
 
==Semaine 6==
 
==Semaine 7==
 
 
==Semaine 8==
 
==Semaine 8==
 
==Semaine 9==
 
==Semaine 9==

Version du 6 mars 2019 à 17:18


Présentation générale

Description

P57-2018-prez.jpg


   Les capteurs sont omniprésents dans le domaine de l'entreprise. Une usine peut disposer de plusieurs centaines de capteurs répartis dans toute sa structure. Ces capteurs ont des rôles différents comme la mesure de la température, la présence d'une pièce où encore la mesure métrique d'un élément. 
Chacun de ces capteurs peut être amené a être mis à jour afin de modifier un temps de réponse ou changer la couleur de détection d'un capteur optique etc...
Ces mise-à-jours peuvent être fastidieuses à implémenter car nécessite l'intervention physique d'un opérateur et la mise à jour se fait pour chaque capteur individuellement.

Objectifs


L'objectif de ce projet est de proposer un système permettant de reprogrammer un capteur de manière OTA (Over The Air) sans aucune intervention physique.

Le système devra être :

  1. Sécurisé : la mise à jour devra être vérifié (provenance, checksum) avant l'implémentation.
  2. Économe en énergie : l'impact énergétique sera pris en compte dans le choix des technologies.
  3. (Bonus) Le système sera générique afin de pouvoir mettre a jour un groupe de capteur automatiquement

Analyse du projet

Positionnement par rapport à l'existant

Un système semble déjà exister pour les composants ATmega328P(arduino) [1]
Le but de ce projet sera de créer un module indépendant qui devra respecter certains critères afin de pouvoir être polyvalent et s'appliquer a chaque capteur. Ce module sera ajouté à chaque capteur lors de sa fabrication. Une étude du coup supplémentaire sera alors effectuée.

  1. Polyvalence : le module pourra s'implémenter à chaque capteur facilement sans ajouter un code particulier.
  2. Sécurisé : chaque mise à jour sera contrôlée avant l'implémentation du programme. (calcul du MD5 Checksum + Clée de décryptage)
  3. Économe en énergie : ce module devra utiliser le moins possible de courant. Les composants seront donc choisis pour leurs consommation.


Avantages :

  1. Hautement sécurisé : chaque mise à jour sera vérifiée à l'aide d'une clé de cryptage et d'un checksum.
  2. Peut théoriquement s'adapter à tout type de capteur.
  3. Temps de mise hors service très court. (Par rapport à une maintenance physique)


Inconvénients :

  1. Coûts de fabrication plus important

Analyse du premier concurrent

MYSBootloader by Tekka (Mysensors Team)

Ce système fonctionne en tant que bootloader uniquement sur les microcontrôleurs ATmega328P. Lors du boot du microcontroleur ou reset, il applique la mise à jour du code qu'il a reçu. Lors de la réception de la mise à jour le capteur doit être offline.
Ce système ne nécessite pas de mémoire externe.

Avantage :

  1. Si le firmware est défectueux, il est possible de réimplémenter

Inconvénients :

  1. Le capteur doit être en mode hors-ligne afin de pouvoir se mettre à jour (il doit rebooter)
  2. le bootloader dépend énormément du module radio (un bootloader différent pour chaque module radio)

Analyse du second concurrent

Dualoptiboot by Lowpowerlab

Cette solution est une solution codée dans le firmware à implémenter. Elle nécessite une mémoire externe afin de stocker le firmware reçu avant de le téléverser dans la mémoire interne du microcontrôleur. En incluant la librairie Dualoptiboot, un programme scrutant les mise-à-jour est continuellement exécuté.

Avantages :

  1. Ne dépend pas du module radio.
  2. Peut être mis à jour en fonctionnement

Inconvénients :

  1. Un firmware défectueux ne peut plus être mis-à-jour OTA
  2. Nécessite une mémoire externe

Positionnement par rapport a la concurrence

Les concurrents utilisent le système radio comme communication entre un serveur et plusieurs capteurs. Cette communication s'effectue dans les deux sens et permet de réaliser un diagnostic et envoyer les mises a jour en clair via les ondes radios. Cependant ces mises à jour ne sont pas cryptés. De plus n'importe quel ordinateur sur le réseau pourrait envoyer les mises à jour sans qu'il y ai de vérification de sécurité.
Pour faire simple, la solution proposée par les concurrents est surtout utilisé pour effectuer de la domotique ou d'autres taches au domicile. Cependant, la sécurité est quand a elle insuffisante pour l'implantation dans l'entreprise.
Une clée de cryptage sera attribuée à chaque entreprise. Le système proposé sera différent de :
MYSBootloader par :

  1. Le bootloader contiendra toutes les fonctions permettant de décoder les trames reçues.
  2. Il exécutera en plus du code du capteur, un processus de scrutation du signal radio et lors de la réception d'une mise-à-jour, stockera et traitera les informations. Au lieu d'écrire directement. (Par l'implémentation d'un ordonnanceur)
  3. La mise à jour pourra être reçue en fonctionnement sans avoir a rebooter


Dualoptiboot par :

  1. Mis-a-part le checksum, aucune vérification de sécurité n'est réalisée.
  2. L'algorithme de sécurité contenant la clé de décryptage ne peut pas être contenue dans une librairie transmise au client. (Un usager mal intentionné pourrait exploiter ces données pour pouvoir diffuser de fausses mise-à-jour)
  3. L'utilisateur n'aura pas a recompiler à chaque fois la partie gestion du module radio.


Cependant ces différences apportent leurs lots de contraintes :

  1. Une place utilisée sur la mémoire interne de l'Atmega plus importante.
  2. Un temps de traitement plus long lors de la vérification des mises à jour
  3. La nécessité d'avoir une mémoire interne afin de réaliser le traitement

Scénario d'usage du produit ou du concept envisagé

légende

Scénario :


Le chef d'entreprise doit mettre à jour ses capteurs afin de pouvoir gagner en productivité (envoi de donnée plus rapide). Un technicien doit démonter et reprogrammer un a un plusieurs centaines de capteurs alors que son chef lui demande d'aller plus vite car la chaine de production est interrompue. Quand SensorOTA propose de mettre a jour en quelques secondes tous les capteurs à l'aide d'une antenne et de la communication broadcast avec presque aucune coupure.


Réponse à la question difficile

Comment faire pour que l’ATMEGA puisse se reprogrammer toute seule ?
Pour pouvoir écrire dans l'EEPROM (la mémoire interne de l'ATMEGA), il faut posséder une autre mémoire (vive ou morte). Le choix s’oriente vers une EEPROM pour plusieurs raisons :

  1. La consommation énergétique presque nulle en dehors des lectures et écritures.
  2. La mémoire conserve la mise à jour même si elle est déconnecté du réseau (mémoire morte).

Cependant, d'autres facteurs peuvent être contestés :

  1. Le coût est légèrement supérieur a un autre type de mémoire (mémoire vive)
  2. Durée de vie plus courte (10 000 écritures)



L'Atmega peut réécrire son programme interne grâce au bootloader. Le bootloader est une portion de code qui s'exécute avant le programme principal. Actuellement, le bootloader optimise la vitesse d'exécution du code.
Des bootloader alternatifs existent, c'est le cas notament de celui de Dave Berkeley site WEB[[2]] Github : [[3]]
Toutefois, celui-ci ne s'occupe pas de la sécurité nécessaire a une mise en production ainsi que l'identification d'un capteur spécifique.

Préparation du projet

Cahier des charges

Le projet choisi doit permettre une implémentation en usine ainsi qu'une commercialisation possible. Pour cela de nombreux aspects doivent êtres analysés.

  1. Le système devra avoir une portée suffisante (environs 50m)
  2. L'ATMEGA ne sera reprogrammé qu'après avoir acquis la certitude que la mise à jour est authentique (Algorithme par cryptographie symétrique + Checksum)
  3. La transmission de mise-à-jour devra être cryptée afin d'éviter qu'une écoute réseau révèle le contenu de celle-ci. (Données cryptées envoyées sur le réseau)
  4. La consommation du capteur ne devra pas augmenter de plus de 10% de la consommation habituelle
  5. Les performances du capteur ne devront pas être impactées en dehors des mises à jour.


De plus d'un point de vue architecture :

  1. Le système utilisera des composants répandus sur le marché afin de pouvoir être réparé a moindre frais
  2. Le système n'utilisera pas de CMS afin de pouvoir être entretenu par l'utilisateur. (Et aussi afin de pouvoir réduire les couts de fabrication)
  3. Un autre moyen de reprogrammation devra être implémenté afin de pouvoir mettre a jour manuellement (en cas de panne).

Choix techniques : matériel et logiciel

Matériel nécessaire : (pour la partie capteur)

  1. ATMEGA328P-Au x1 [4]
  2. USB-TTL Arduino Programmer
  3. Flash 128kB [5]
  4. SRAM 128kB [6]
  5. NRF24L01 [7]
  6. BreadBoard
  7. 16Mhz oscillator [8]
  8. Capacitors
  9. 3v3 regulator [9]
  10. Led x1
  11. Resistance x1

Matériel nécessaire : (pour la partie émetteur)

  1. Raspberry Pi [[10]]
  2. NRF24L01 [11]
  3. 1 ecran lcd Raspberry pi [12]

Choix Logiciel :
Je choisis de m'inspirer du programme concurrent MYSBootloader qui sera modifié afin de permettre la mise à jour pendant le fonctionnement. FreeRTOS pourra être utilisé dans ce projet.

L'architecture de la mémoire sera semblable a celle trouvée sur les Arduino.

Liste des tâches à effectuer

Taches à effectuer (dans l'ordre)

  1. Conception du capteur
  2. Mise en place de la Raspberry
  3. Mise en service de la Raspberry
  4. Création du programme de communication de la Raspberry
  5. Modification du bootloader afin d'écrire sur le programme principal

BONUS :

  1. Mise en place du protocole de sécurité
  2. Attribution de clés uniques via la Raspberry Pi (communication via le port série)
  3. Programme pour que la Raspberry puisse flasher le bootloader et attribuer la clé de sécurité

Calendrier prévisionnel

Réalisation du Projet

Feuille d'heures

Tâche Prélude Heures S1 Heures S2 Heures S3 Heures S4 Heures S5 Heures S6 Heures S7 Heures S8 Heures S9 Heures S10 Total
Analyse du projet 0 4 8

Prologue

Semaine 1

Définition des fonctionnalités de la carte, première phase de conception, choix des composants selon les besoins du projet. Choix d'une technologie de mémorisation SRAM au lieu d'une technologie EEPROM (pour sa durée de vie, sa consommation électrique, son prix). La persistance des données n'étant pas un absolue. J'ai pris la décision de penser le programme différemment. Lors de la réception d'une mise à jour, le micro-contrôleur la stockera dans la mémoire SRAM et effectuera les vérifications de celle-ci. Une fois la mise à jour vérifiée, le micro-contrôleur transférera les données directement dans la mémoire de programme.

Concernant le module radio, un emplacement sera disponible (header) afin de pouvoir attacher le circuit directement sur la carte. Cela permet d'utiliser le modèle déjà existant et également pouvoir le changer pour de la maintenance.

Le schématique a été commencé et la recherche des différentes empreintes a commencé avec parfois, la requête à un service de création d'empreinte.

Semaine 2

Schématique
Mémoire ATMEGA

Cette semaine, une semaine où la conception du circuit récepteur devient primordiale. Mise en place d'un schématique lisible qui permet de répondre aux besoins.

Une concertation avec les encadrants m'a permis de définir plusieurs choses. Premièrement, qu'il fallait mettre les deux types de mémoire afin de pouvoir les comparer d'un point de vue énergétique, pratique etc. Une mémoire flash sera donc ajoutée au schématique afin de permettre la commutation entre les deux mémoires.

La deuxième chose est que le programme OTABoot pourra se situer dans deux espaces :

  1. A la fin de la mémoire de programme en prenant garde que le programme à mettre dans l'espace mémoire de programme ne réécris pas cette partie.
  2. Dans la partie Bootloader (qui est extensible jusqu'à 4ko) ce qui évitera que celui ci soit supprimé par une manipulation utilisateur.

La fonction OTABoot devra pouvoir stocker temporairement dans la mémoire (RAM ou Flash) les données reçu jusqu'à la fin de la réception et vérifier la conformité des données reçu avant de flasher l'espace mémoire.

Semaine 3 à 7

Conception du circuit électronique

Semaine 8

Semaine 9

Semaine 10

Semaine 11

Documents Rendus