K2000

Sébastien Ballut
4 déc. 2020
6 min de lecture

Dernière mise à jour : 2 juil. 2021

Présentation

Le projet K2000 est un projet réalisé durant mon deuxième semestre d'étudiant à INTECH lorsque nous devions travailler sur des technologies du Web avec des bases de données. Un projet ambitieux qui permettrait d'analyser les données d'un véhicule en temps réel dans le but de prodiguer des conseils de conduite adaptée.

Contexte

Un jeune entrepreneur nous a contacté pour développer un POC (Proof Of Concept). L'objectif de ce POC consistait à capturer les données de véhicules afin d'assurer un suivi mécanique en temps réel de ceux-ci. A partir des données recueillies, il nous incombait de créer une application capable de monitorer ces données (les surveiller en temps réel avec un appareil de suivi automatique), afin de pouvoir donner des conseils au conducteur pour l'aider à conduire de manière plus économique et plus écologique.

Notre client souhaitait également que l'application soit capable de détecter les feux de signalisation et de prédire le moment où le feu changerait de couleur, afin que le conducteur puisse adapter sa vitesse à son approche.

L'enjeu pour ce client est de vendre cette application aux compagnies d'assurances, qui seraient alors en mesure de posséder davantage d'informations sur la conduite de leurs adhérents et de pouvoir ainsi adapter leurs tarifs à partir de ces indicateurs.

La réalisation de ce projet n'est pas sans risque pour notre client puisque nous sommes des étudiants débutants. Serons-nous capable de réaliser son cahier des charges à la fois techniquement et dans les délais impartis? Parviendrons-nous à répondre à ses attentes? Toutefois, il n'y a pas de risques financiers pour lui puisque ce projet réalisé par des étudiants ne lui coute rien financièrement.

De notre côté, il nous faudra veiller aux risques techniques (langages et technologies à utiliser), aux risques humains (entente, implication et compétences de chaque membre de l'équipe), aux risques liés à la gestion de projet (affectation des responsabilités sur les tâches, bonne répartition des rôles dans le projet, implication de l'ensemble de l'équipe projet: développeurs et commanditaire) et bien évidemment au risque du délai (nécessité d'une bonne estimation initiale de la durée nécessaire à l'exécution de l'ensemble des tâches).

Plan d'action

Sur ce projet, nous sommes une équipe de trois étudiants avec certaines contraintes imposées par l'école dans un but pédagogique. Nous sommes surtout bridés par les langages informatiques que nous devons utiliser: Javascript, HTML/CSS, PHP et c'est tout ! Des langages qui ne sont pas forcément adaptés pour de l'IoT (Internet des objets) ou des systèmes embarqués.

Mais pas de soucis pour nous: Challenge accepted !

Peut-être qu'une des requêtes du commanditaire vous a un peu interpellée? En effet, après une réflexion assez rapide, nous avons décidé d'écarter la partie qui consistait à anticiper les changements de couleur des feux de signalisation. Il y avait beaucoup trop de contraintes par rapport à cette partie, comme le fait d'avoir accès à une base de données de gestion des feux, ou encore le temps imparti pour réaliser l'ensemble du projet (6 mois).

Les priorités ont été définies avec le commanditaire comme suit:

Avoir une interface capable de monitorer des données sur smartphone (Android)
Récupérer et afficher les données d'un véhicule en temps réel
Donner des conseils de conduite au conducteur
Détecter des défauts moteur

La première étape a consisté pour moi à concevoir un simulateur de véhicule capable d'envoyer des données factices (vitesse, régime moteur, …) en continu vers une base de données distante. En parallèle, le reste de l'équipe s'est occupé à créer la base de données et une interface web responsive capable d'afficher les données. La base de données, le simulateur et une première version de l'interface ont été rapidement mis en place sans grandes difficultés. Cela nous a permis de passer sans tarder à une phase de recherche et de développement concernant la récupération des données du véhicule. C'est la phase qui nous a pris le plus de temps en raison du manque d'informations dont nous disposions sur ce sujet. La seule information en notre possession était qu'il nous fallait un lecteur sans fil pouvant se connecter sur la prise OBD 2 de chaque véhicule.

Lecteur pour prise OBD 2

Ce lecteur est capable de récupérer les informations circulant sur le bus de données CAN du véhicule et de les transmettre en Wi-Fi ou Bluetooth selon le modèle de la prise. Pour ce projet nous disposions des deux modèles de lecteur.

Que pouvons-nous faire alors ? Créer une application mobile qui traite les données reçues de la prise ? Très bonne idée ! Mais les technologies nous permettant de créer une application mobile nous sont interdites … .Alors comment faire ?

Commençons par faire un point de ce dont nous disposons et ce dont nous avons besoin:

Nous avons une interface web capable de lire des informations sur une base de données distante.
Nous avons un lecteur de prise OBD 2 capable d'envoyer les données du véhicule en Bluetooth ou en Wi-Fi.
Nous avons besoin d'envoyer ces données dans la base de données afin que l'interface puisse les lire.

Il nous faut donc un outil capable de réceptionner des données en Bluetooth et/ou Wi-Fi et de les transmettre à un serveur. Notre choix s'est rapidement porté vers un Raspberry Pi. Plus précisément, le Raspberry Pi modèle 3. C'est un nano ordinateur de la taille d'une carte de crédit que l'on peut brancher à un écran et utilisé comme un ordinateur standard.

Nous avons choisi un modèle disposant d'une carte Wi-Fi et du Bluetooth. Ce choix a donné lieu à une architecture particulière de solutions.

Architecture de la solution

Résumons maintenant un peu tout cela!

Le lecteur connecté sur la prise OBD 2 du véhicule transmet les données au Raspberry (branché sur l'allume-cigares) qui les traite et les envoie sur un serveur grâce au partage de connexion du smartphone. Le smartphone n'aura plus qu'à lire les données sur le serveur et le tour est joué!

Mais c'est à ce moment-là que les difficultés ont réellement commencées. Effectivement, récupérer les données s'est avéré plus complexe que prévu. Nous avons dû faire énormément de recherches pour comprendre comment la prise envoyait les données. Ces deux sources nous ont été indispensables: La page Wikipédia référençant tous les ports de la prise OBD 2 et un projet Javascript capable de lire les données de la prise. Après de nombreuses recherches et de multiples tests, nous avons finalement réussi à récupérer les données de la voiture sur le Raspberry. Il nous faut maintenant les transmettre au serveur. Pour cela, nous avons utilisé un script envoyant un fichier JSON comportant une série de données au serveur via un protocole FTP.

En effet, nous n'avons pas réussi à insérer directement les données dans la base de données prévue initialement. Nous avons donc dû légèrement modifier le code permettant de lire les données sur le serveur.

A la suite de ces premiers résultats fructueux, il a ensuite été nécessaire de configurer le Raspberry afin qu'il se connecte automatiquement au partage de connexion du smartphone et au Bluetooth de la prise OBD 2.

Durant toute cette phase de recherche et de développement, une partie de l'équipe a travaillé sur l'interface web, sur les fonctionnalités liées aux comptes utilisateurs (création de compte, gestion des véhicules et des données utilisateurs, …) ainsi que sur les conseils à donner au conducteur comme "Passer la vitesse" par exemple.

A partir de là, place aux tests !

Résultats

Les tests ont été réalisés sur plusieurs véhicules différents.

Liste des véhicules testés

D'après les résultats obtenus, nous en avons déduit que plus le véhicule était récent, plus on arrivait à extraire de données.

Voici une vidéo de démonstration que nous avons réalisée pour présenter le projet:

Vous avez peut-être remarqué sur la vidéo un temps de latence d'environ 3 secondes, et vous avez raison, il ne s'agit pas d'un défaut de montage. Nous pensons que ce temps de latence est dû à l'architecture de la solution que nous avons mise en place. Effectivement, il y a de nombreuses opérations avant que l'interface puisse lire la donnée, ce qui augmente considérablement le temps de latence.

Nous n'avons pas réussi dans le temps imparti à finaliser la partie concernant le diagnostic moteur, car nous n'avons pas eu le temps de réaliser suffisamment de tests pour la considérer comme fonctionnelle.

Conclusion

Même si le produit n'est pas entièrement terminé quand on tient compte de la partie diagnostique moteur. Le commanditaire était tout de même satisfait car il a tout de même un produit en grande partie fonctionnel pouvant servir POC pour trouver un financement pour le développement définitif du projet.

Ce projet, particulièrement enrichissant m'a donné le goût de l'IoT et m'a permis de faire mes premiers pas dans l'utilisation d'un Raspberry. Si je devais refaire ce projet, il est évident que je modifierais considérablement l'architecture en supprimant des intermédiaires comme le Raspberry et le serveur distant et que je me débrouillerais pour envoyer les données du véhicule directement sur le smartphone qui les enverrait sur un serveur distant. Nous pouvons également remettre en question certaines fonctionnalités de la solution quant aux conseils donnés au conducteur qui sont maintenant présents dans la quasi totalité des véhicules récents.

Cependant, les données destinées aux assurances pourraient selon moi constituer un véritable marché à condition d'avoir l'approbation des utilisateurs.

Anecdotes

Ce projet nous a donné du fil à retordre en particulier au moment des tests. Effectivement, nous n'avions pas accès à un environnement propice pour réaliser ce genre de tests et nous avons dû nous débrouiller avec les moyens dont nous disposions. Cela a donné lieu à des situations parfois comiques comme le fait de faire passer les rallonges et des câbles réseaux de 20 mètres par les fenêtres de l'établissement scolaire. En effet, la portée du Bluetooth ne nous permettait pas d'effectuer des tests depuis la salle de classe.