CarLoRA

Introduction

Nous avons choisi de participer à la réalisation du projet CarLoRa.
L’objectif de ce projet était de traiter des données de conduites.Nous avons utilisé une board Pycom LoPy sur une carte d’extension Pytrackmunie d’un GPS notamment. Les données de conduites ont ́et ́e récupérées par unappareil ODB2 ELM 327. Nous n’avons pas pu réaliser ce projet en raison de problèmes techniques. En effet, les technologies Bluetooth de la carte LoPy et de l’ELM327 sont incompatible. Une solution a ́eté de simuler les données retournées par la carte LoPy en LoRa et de les traiter, puis les stocker dans une blockchain Ethereum.

Présentation du projet

Motivations

L’idée du projet CarLora est de récupérer, analyser et stocker les données de conduite d’un utilisateur. L’usage principal de telles données est la personnalisation du contrat d’assurance d’un utilisateur. Si la conduite est jugée plus risquée alors sa prime d’assurance est augmentée et inversement dans le cas d’une ”bonne”conduite. Il s’agit du concept de ”Pay how you drive” utilisé dans les assurances outre-atlantique principalement.La principale limite de cette méthode est le respect de la vie privée des utilisa-teurs dans la mesure où leurs déplacements sont enregistrés.

Choix Techniques

Le projet CarLora consiste donc à récupérer des informations de conduite par le biai d’un appareil ODB2 ELM327, de les envoyer par bluetooth à une carte Pycom LoPy pour être envoyée en Lora à un broker située hors de la voiture.

Appareil ELM327 ODB2

Cet appareil se branche à la prise ODB2 de la voiture. Il est principalement utilisé pour effectuer un diagnostic de la voiture. En effet le protocole OBD2 défini l'interface standard d'accès au système de diagnostics embarqués. Plus récemment la norme est utilisée pour contrôler les différentes données relatives à la pollution et à la consommation du véhicule. Il existe de nombreuses applications Android permettant d'analyser les valeurs retournées par l'appareil ELM327. Ces applications permettent de réaliser un diagnostic ou de surveiller certaines valeurs

Dans le cas du projet certaines métriques retournées peuvent être utilisées pour analyser la conduite utilisateur, comme par exemple la vitesse ou l'accélération.

Carte Pycom LoPy et Pytrack

La carte PyCom Lopy dispose d'une connexion Bluetooth Low Energy et d'une antenne Lora pour émettre des informations vers un broker Lora. L'idée était ici de connecter la carte LoPy au module ELM327 en Bluetooth et d'envoyer les informations jugées utiles à l'analyse de la conduite en Lora à un Broker.

Par ailleurs, la carte LoPy et sa board Pytrack offrent également d'autres fonctionnalités exploitable pour analyser la conduite. On pourra par exemple citer un module GPS ou un accéléromètre pour détecter les changements brutaux de trajectoire.

Métriques de conduites retenues

Nous avons sélectionné 3 métriques représentant la conduite d’un utilisateur:

La vitesse: De manière générale, plus un véhicule vas vite, plus le risque d’accident augmente (Même si ceci est faux sur autoroute).

La rotation du volant: De manière générale un grand nombre de coup de volant brusque ne sont pas signe d’une conduite souple et sécuritaire.

Le nombre de rotation par minute du moteur : Le nombre de RPM est relativement lié à l'accélération du véhicule. Un nombre de RPM élevé signifie probablement une brusque accélération.

Ces paramètres sont également analysables de manière simultanée par exemple accélérer en tournant le volant n'est pas recommandé et signe d'une conduite peu sûr.

Nous nous sommes limité à trois valeurs analysées en raison principalement des contraintes de temps. Il aurait été par exemple intéressant d'analyser le type de route sur lesquelles l'utilisateur conduit grâce à la position gps.

Spécifications techniques

Appareil ELM327 et norme ODB2

La norme ODB défini par défaut 10 modes de diagnostic utilisable au travers de plusieurs protocoles de transmission. Les véhicules plus récents (à partir de 2003) peuvent utiliser le protocole CAN plus rapide. Les principaux mode sont:

Mode 1: permet des lires les valeurs des sondes et capteurs du moteur (vitesse, température etc.)

Mode 3 et 7: permettent de lire les défauts moteur

D’autres modes existe pour par exemple effacer des codes d’erreurs.

Carte Pycom LoPy et Pytrack

Pycom est une société hollandaise fabriquant des cartes de prototypage. La carte LoPy est particulièrement innovante dans le fait qu'elle intègre dans une seule carte 3 radios de communication (Wifi, Bluetooth et LoRa). Les spécifications partielles de la carte LoPy sont:

   512KB de RAM
   4MB de Flash
   Accélération matériel pour les calculs en virgule flottante
   Support de MicroPython
   Multi-threading (sous MicroPython)
   WiFi  802.1b/g/n 16mbps
   Bluetooth  Low Energy et classique (mais aucune bibliothèque n’est disponible pour la version classique)
   LoRa  – Semtech LoRa transceiver SX1272
   Dual processor + WiFi radio System on chip
   24 broches GPIO
   Power  – Input: 3.3V – 5.5V

Les bibliothèques fournies pour MicroPython sont encore en cours de développement, Certaines fonctionnalités ne sont pas encore disponible pour la programmation d'applications utilisateur. Toutefois, ces fonctionnalités devraient être implémentées prochainement.

MicroPython est un langage dérivé de Python 3.5 conçu pour fonctionner sur des micro-controlleur. Il permet théoriquement de développer des applications plus rapidement et plus simplement en comparaison au langage C couramment utilisé dans ce domaine.

Projet original (LoPy et ELM327)

Premi`ere r ́ealisation

Nous avons commencé par vérifier le fonctionnement de l’appareil ELM327 à l’aide d’une application Android. Ceci nous a notamment permis de nous familiariser avec la norme ODB2 et de choisir diverses métriques à retenir dans le cadre de notre projet.

Ayant reçu la carte LoPy neuve, nous avons dû mettre à jour le firmware de la carte LoPy et de PyTrack avec les firmwares récupérés sur le site de Pycom à l’aide de l’utilitaire DFUTools.

Nous avons ensuite installé et configureé le plugin “Pymakr Plugin” pour Visual Code.

Le plugin nous a permis d’exporter nos programmes en python vers la carte LoPy.

Il était nécessaire d’importer les diverse bibliothèques souhaitée dans l’espace de travail. Les bibliothèques sont disponible sur le GitHub de PyCom [1]

Interface de visualisation Jyse

Le logiciel Jyse nous a permis de créer un dashboard représentant les différentes mesures relevées en temps réel par l’utilisation de 3 sujets MQTT.

Nous avons représenté les valeurs en temps réel des 3 métriques de conduites que nous avions sélectionné (vitesse, rotation et RPM moteur). L’historique de la vitesse par rapport au braquage du volant a également été représenté.

Problème rencontré

Nous nous sommes aperçu tardivement, suite à des résultats incohérents, que les normes BLE et Bluetooth classique n'était pas compatible. Le problème étant que l'appareil ELM327 fourni ne fonctionnait qu'en Bluetooth classique avec "pairing" et la carte LoPy ne supportant pour l'instant que le BLE.

Le BLE ou Bluetooth à basse consommation a été développée par Nokia en 2006 pour devenir un standard ouvert. Il fonctionne dans sur la même plage de fréquence que le Bluetooth classique (2.4 - 2.5Ghz) et est davantage orienté vers l'IOT. Le BLE est moins adapté pour le transfert de fichiers de taille importante.

La modulation de la fréquence diffère entre le Bluetooth et de BLE de même que le nombre et type de canaux de communication. La taille des messages (les messages sont plus volumineux pour le Bluetooth classique) varie également. De ce fait il n'est pas possible d'associer deux périphériques BLE et Bluetooth classique, il est nécessaire que les deux périphériques utilisent la même norme.

Nous n'avons donc pas pu poursuivre notre projet en utilisant la carte LoPy et le module ELM327 pour récupérer les informations de conduite.

Solution réalisée

Afin de continuer le projet malgré l’incompatibilité entre la carte LoPy et le module ELM327, nous avons choisi de simuler les données de conduite par le programme serveur en JAVA que nous réalisions.

Back-End JAVA

Notre Back-End a été réalisé en Java et dispose de 3 fonctionnalités principales: la simulations de données, le traitement des données et l'enregistrement des données sur une blockchain Ethereum.

Simulation de données de conduites

Nous avons conservé le choix initial de travailler sur 3 données de conduites: La vitesse, le nombre de RPM du moteur ainsi que la rotation du volant. Nous avons choisi arbitrairement que la vitesse serait comprise entre 0 et 200 KM/h, le nombre de RPM entre 0 et 6000 et la rotation du volant serait comprise entre -180 et 180°.

La simulation garde en mémoire la valeur précédente et la fait varier de manière modéré dans une direction en respectant les valeurs minimum et maximum. La simulation n’est bien sûr pas conforme à un test en situation réel.

Un thread génère des valeurs à intervalle régulier et les publies sur le sujet de type /carlora/lopy/ sur le broker mqtt spécifié.

Récupération de données de conduites

Ce client MQTT nous permet de créer un objet de souscriptions aux sujets MQTT /carlora/lopy/+. Nous récupérons ainsi les valeurs des variables produites par le simulateur via le broker MQTT. nous les stockons dans un objet que nous stockerons dans la blockchain une fois complet (c'est-à-dire lorsque nous disposons des trois métriques de conduite considérées).

Pour le développement nous avons utilisé Mosquitto comme broker MQTT local.

Blockchain Ethereum

Nous avons utilisé la Blockchain Ethereum pour stocker les données de conduites recueillies.

Généraliées

La blockchain Ethereum est un protocole d’échange décentralisé écrit en Go, s’exécutant sur plusieurs node ou pair. Les utilisateurs de ce réseau peuvent créer des smart contract (par exemple en solidity) pour stocker des contrats et des données. Ces smart contract sont par la suite consultable publiquement. Même si l’Ethereum est devenue une crypto-monnaie, à la base la blockchain Ethereum n’avait pas cette vocation.

Une interface en ligne de commande pour gérer un noeud du réseau Ethereum est disponible et se nomme Geth.

Private Network

Nous avons créé deux Node Ethereum grâce à un container Docker. Les instructions pour les lancer se trouvent dans le fichier Readme du repository GitHub [2]

On commence par lancer les deux conteneurs Docker contenant Ethereum et Geth, l’utilitaire de gestion en ligne de commande (CLI) d’Ethereum.

L’étape importante est de générer un utilisateur à l’aide du script fourni et d’associer les deux node grâce à leur adresse et leur IP dans le réseau Docker.

Smart Contract

Le smart contract Solidity est très simple et permet de stocker les 3 informations de conduites ainsi que le timestamp associé.

Une fois le Smart Contract créé, nous avons pu le compiler à l’aide de solc et crééer sont wrapper Java grâce à l’utilitaire fourni par Web3J.

Exemple de Smart Contract utilisé:

pragma solidity ^0.4.0;
contract Record {

    uint timestamp;
    uint rpm;
    uint rot;
    uint spd;

    function Record(uint _timestamp, uint _rpm, uint _rot, uint _spd) public {
        timestamp = _timestamp;
        rpm = _rpm;
        rot = _rot;
        spd = _spd;
    }
    
    function getTimestamp() public constant returns (uint _timestamp) {
        _timestamp = timestamp;
    }
    
    function getRpm() public constant returns (uint _rpm) {
        _rpm = rpm;
    }
    
    function getRot() public constant returns (uint _rot) {
        _rot = rot;
    }
    
    function getSpd() public constant returns (uint _spd) {
        _spd = spd;
    }
}

Stockage des données : Bibliothèque Web3J

Une fois le wrapper du smart contract et le réseau ethereum privé déployé, nous avons pu associer notre back-end à la blockchain Ethereum privé de ce réseau. Pour ce faire, nous avons utilisé la bibliothèque Web3J.

Une file d’attente a été utilisée pour gérer les opérations parfois longues d’écriture sur le premier node de la blockchain Ethereum.

De cette manière à chaque fois que les informations de conduites sont complétées, on créé un smart contract et on le publie dans la blockchain.

Limites Nous avons constater de grandes latences et une occupation CPU importante lorsque les deux node Ethereum étaient lancé (ce qui est cohérent avec le fait que nous les avions lancés avec l'argument -mine).

Conclusion

Ce projet nous a permis de découvrir certaines fonctionnalités de l'IOT. Nous avons notamment découvert les technologies de programmation et de communication des périphériques embarqués basses consommation. LoPy est une plateforme de développement récente et très riche en possibilité (de communication notamment) même si certaines ne sont pas encore totalement réalisées et documentées par la société éditrice.
Le logiciel Jyse est très puissant pour obtenir rapidement une visualisation des différentes données retournées par le système. Nous avons également pu découvrir les concepts de base de la blockchain Ethereum.
Toutefois, le problème d'incompatibilité entre le bluetooth classique et le BLE nous a empêché de poursuivre le projet dans les conditions prévues au début. Le réseau privé Ethereum est également très simple et aurait gagné à disposer d'outil de monitoring par exemple.

Références

https://www.elm327.fr/norme-obd/modes-obd/

https://www.outilsobdfacile.fr/interface-diagnostic-elm-327.php

https://pycom.io/wp-content/uploads/2018/03/Pycom_Specsheet_LoPy.pdf

https://docs.pycom.io/

http://www.rfwireless-world.com/Terminology/Bluetooth-vs-BLE.html

https://gist.github.com/fishbullet/04fcc4f7af90ee9fa6f9de0b0aa325ab

https://docs.web3j.io/command_line.html

https://dzone.com/articles/an-introduction-to-ethereum-and-smart-contracts-a

https://github.com/JacqMT/web3j-maven-example/wiki/Smart-Contracts-in-Java

http://solidity.readthedocs.io/en/v0.4.21