En 2018, UBIDREAMS a réalisé un projet de Proof of concept pour une société d’autoroute pour la gestion des Alertes Contresens. Ce texte décrit la perception d’UBIDREAMS sur la démarche globale à l’issue du projet de POC qui a été mené de juin à Décembre 2018. Il commente les résultats obtenus et les perspectives sur la stratégie de déploiement qui pourrait être mise en place à l’issue de ces travaux exploratoires sans toutefois dévoiler ni les mesures réalisées, ni la position choisie et retenue par le Client d’UBIDREAMS. Il respecte donc l’engagement de confidentialité d’UBIDREAMS.

 

L’idée originale du projet confié à UBIDREAMS consistait à placer des “beacons, sorte de balises émettant un signal bluetooth unique, le long d’une autoroute à intervalle régulier pour permettre aux usagers de cette autoroute d’être alertés en cas de circulation à contresens d’un autre usager grâce à cette infrastructure. Le principe est simple, lorsqu’une zone d’alerte est connue par le système de gestion de l’exploitant d’autoroute, les “beacons” positionnés sur cette zone sont repérés par le système crée par UBIDREAMS et permettent de déclencher au passage des voitures une alerte sonore et visuelle sur le smartphone des usagers.

 

Autoroute connectée

 

Pour éviter que l’usager ait à télécharger l’application qui permet de déclencher ces alertes, préalablement à la fréquentation de l’autoroute, UBIDREAMS a réalisé non pas une application mobile dédiée à la fonction d’alerte mais un SDK (Software Kit Development) capable de s’interfacer avec des applications déjà existantes comme celle de l’exploitant de l’autoroute et d’autres très utilisées par les clients de l’autoroute comme Coyote ou Waze, charge à l’exploitant de l’autoroute de négocier avec ces fabricants d’applications pour y faire insérer ce SDK une fois développé dans leurs applications.

Dans la réalisation des développements et des essais, UBIDREAMS est arrivé à démontrer plusieurs choses concrètes.

  • Premièrement, qu’il y a une très bonne détection, par tous les smartphones du marché et à haute vitesse, des signaux émis par les beacons de la société qualifiée et retenue par UBIDREAMS à l’issue de la phase 1 du POC et lors des discussions de la phase 2.
  • Deuxièmement que l’on arrive toujours à repérer et à déclarer dans le système UBIDREAMS en temps réel, les “beacons” concernés par des zones d’alertes grâce aux notifications silencieuses gérées dans le SDK fabriqué par UBIDREAMS.
  • Troisièmement que l’algorithme de génération d’alerte sonore et visuelle fonctionne parfaitement dans tous les cas et pour tous les smartphones lorsque l’application embarquée sur le smartphone de l’usager est en mode active ou en tâche de fond.
  • Quatrièmement, que la génération d’alerte est aléatoire lorsque l’application résidente sur le smartphone de l’usager est en mode éteint.  Dans ce mode “application éteinte”, les paramètres qui semblent influencer les résultats sont nombreux et de nature différente.

La perception d’UBIDREAMS à l’issue de cette phase exploratoire de développement et d’essais est que l’idée du BEACON comme infrastructure est une bonne idée qui mérite d’être creusée et développée pour deux raisons principales.

 

D’une part, UBIDREAMS considère que les résultats sont encourageants car ils sont très satisfaisants dans les deux modes « actif » et « tache de fond » et qu’ils permettent bien dans ces deux modes de générer une alerte contresens dans 100% des situations et avec tous les téléphones dans un délai assez court qui suit la connaissance du danger par le système de l’exploitant de l’autoroute.

 

D’autre part, UBIDREAMS affirme que l’infrastructure “beacon” permet un maillage nettement plus fin du réseau autoroutier que l’autoriserait un système de « géofencing » sur lequel pourrait reposer une gestion des alertes contresens. En effet, le système de « géofencing » qui comme son nom l’indique repose sur la géolocalisation des smartphones et la capacité à leur envoyer des messages en fonction de la zone dans laquelle ils se trouvent, est limité à une vingtaine de zones par les constructeurs de smartphones. Ainsi, si l’on peut prévoir que le système marcherait mieux en mode application éteinte ce qui reste à prouver, le système ne serait pas précis et les alertes qui seraient générées, seraient diffusées beaucoup trop largement perdant ainsi de leur pertinence. L’idée du BEACON nous semble donc bonne mais c’est l’idée du Smartphone comme récepteur du signal d’alerte qui nous parait faible dans cette architecture. En effet, l’idée du Beacon est bonne car il est beaucoup moins cher que des TAGS Wifi, il consomme beaucoup moins d’énergie et il rend le service qu’on attend de lui puisqu’il est détecté à haute vitesse et qu’il identifie très clairement une zone avec un maillage très fin.

 

Par contre, le smartphone est le maillon faible dans cette logique de prévention car bien que répandu largement auprès des usagers, les politiques des constructeurs de smartphones, Google et Apple sont telles qu’elles empêchent de plus en plus les intrusions par des applications dans le mode « éteint », ceci dans un but unique de préserver la batterie du smartphone qui reste le point faible de cet appareil. Ainsi, on l’a vu dans les essais, les vieilles versions des smartphones avaient des meilleurs comportements en mode application éteinte que les nouvelles et la détection était aussi meilleure lorsqu’ils étaient branchés. Le Smartphone est un excellent récepteur dès lors que l’application qui gère l’alerte est allumée ou en tâche de fond. Si la stratégie est de conserver le smartphone comme récepteur dans la voiture, cela signifie qu’il faut que l’exploitant de l’autoroute crée une politique d’incitation aux entrées de l’autoroute, sur les barrières de péage et sur les aires de repos par des messages, des affiches, des flash radios, pour faire télécharger son application et la faire allumer et bien sûr accentuer les partenariats avec des fournisseurs d’applications routières comme Waze et coyote.

 

Une autre approche pour la gestion d’alerte de sécurité routière serait d’envisager la création d’un récepteur « bluetooth » intégré aux voitures. Ainsi, le système dont la fiabilité a été démontrée par UBIDREAMS dans le cadre de ce projet pourrait s’affranchir de la dépendance des constructeurs de smartphone avec leurs “operating system” Google ou APPLE, des accords hypothétiques avec les fabricants d’applications comme WAZE ou Coyote et du téléchargement par les utilisateurs des applications mobiles.

 

UBIDREAMS dispose d’un département objet connecté et peut apporter des éléments de réponse pour la conception d’un tel récepteur en travaillant avec des constructeurs ou des équipementiers automobiles.

 

 

 

 

 

 

 

 

 

 

 

 


Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *