Difference between revisions of "VT2020 - Nearby Communications Fiche"
Remy.Palomo (talk | contribs) |
Manon.Chaix1 (talk | contribs) |
||
| Line 1: | Line 1: | ||
| + | Nearby est une plateforme lancée par Google en 2014. Elle est composé de deux API, Nearby Connections et Nearby Messages. Ces API permettent de faciliter la connexion entre des appareils situés à proximité (par exemple de pouvoir s'envoyer un message sans avoir besoin d'un numéro de téléphone). |
||
| − | Contrairement à ce que son nom laisse supposer, Apollo n'a rien à voir avec la NASA, mais est ici une plateforme de conduite autonome open source qui a été publiée par la société Baidu Research en 2017. L'objectif étant de développer des voitures totalement autonomes d'ici 2020. Ce délais semble assez court, mais Baidu estime que l'open source permettra d’accélérer les tests et le déploiement. |
||
| − | (Son nom fait tout de même référence aux missions Apollo de la NASA entre les années 1960 et 1970). |
||
| + | == Description des API == |
||
| − | == De nombreuses versions au fil du temps == |
||
| + | Nearby est en réalité constitué de deux API : Nearby Connections et Nearby Messages. Elles apportent des services similaires mais avec des caractéristiques différentes. |
||
| − | [[File:Versions.png|1000px|thumb|Schémas représentant les différentes versions d'Apollo existante]] |
||
| + | '''Nearby Connections API''' |
||
| + | L'API Nearby Connections permet de créer une connexion local entre des appareils à proximité en temps réels. Par exemple, elle rend possible d'associer des appareils et de s'en servir pour des jeux multijoueurs. La connexion est donc limité au réseau local : tous les appareils doivent être sur le même réseau Wifi. La communication n'est possible qu'entre des appareils Android. Son principe de fonctionnement ressemble à une architecture Client-Serveur que nous détaillons plus bas. |
||
| + | '''Nearby Messages API''' |
||
| + | L'API Nearby Messages permet plutôt d'envoyer des messages entre appareils, de toute nature mais limité à une certaine taille. Elle rend donc possible des groupes de discussion ou encore la diffusion de ressources. Pour se servir de cette API, les développeur ont besoin de clés API fournies par un compte Google. Les appareils souhaitant communiquer doivent être connectés à internet mais pas nécessairement sur le même réseau Wifi. La communication est possible entre des appareils Android et IOS. |
||
| + | == Principe de fonctionnement == |
||
| + | Pour permettre cet appariement de proximité, les deux API vont mélanger les avantages et les inconvénients de technologies comme le Wifi, le Bluetooth (standard et BLE), et les ultrasons. |
||
| + | '''Nearby Connections API''' |
||
| + | Le principe de fonctionnement de Nearby Connections est assimilable a une architecture Client-Server (OneToMany). |
||
| + | '''Nearby Messages API''' |
||
| + | Le principe de fonctionnement de Nearby Messages est assimilable a une architecture ManyToMany. |
||
| + | Comme on peut voir sur ce schéma, l'appareil A va envoyer une requête sur Google Cloud pour "s'inscrire" avec un Token (ici TA). Il peut également publier en même temps les données qu'il souhaite diffuser donc ici son nom "iPhone 6" avec le tag "name" (Étape 1). Comme on utilise le Cloud on a besoin des clés API et d'une connexion internet. |
||
| + | Pour obtenir ces données, le téléphone B soit "s'abonner" aux données marquées par le tag "name" (Étape 2). |
||
| + | L'appareil A va ensuite diffuser son Token aux appareils autour de lui grâce au Bluetooth et aux ultrasons, pendant que l'appareil B va écouter ce qu'il se passe autour de lui (Étape 3) |
||
| + | Une fois que B a capté le Token de A, il le signale au Cloud et récupère la donnée correspondante (Étape 4 et 5). |
||
| + | On constate donc qu'aucune donnée n'est physiquement échangée entre les deux appareils : tout transite par le Cloud. |
||
| + | '''Pourquoi utiliser ces moyens de communication ?''' |
||
| + | Utiliser un mélange de Bluetooth et d'Ultrasons permet de tirer partie des forces de chacun. |
||
| + | Les ultrasons communiquent via le haut parleur et le micro des appareils, ils ont une courte fréquence de transmission qui leur permet de ne pas traverser les murs. Et c'est ce qui ressemble à ce que l'utilisateur voudrait : que sa conversation ne sorte pas de la pièce. Mais si les hauts parleurs ou le micro d'un des deux terminal est éteint alors la communication est impossible. |
||
| + | C'est pour cela qu'elle est complétée par du Bluetooth. Celui ci est toujours disponible mais a une fréquence d'émission bien trop grande qui permet de traverser les murs. |
||
| + | Il y a donc un intérêt à mélanger ces deux modes de communications : la portée des ultrasons et la disponibilité du Bluetooth. |
||
| + | '''Et au niveau du code ?''' |
||
| + | Pour utiliser l'API Nearby Messages, on a besoin seulement de deux méthodes : publish (pour envoyer des messages) et subscribe (pour les recevoir). Les messages transmis sont des Bytes Array, qui peuvent contenir n'importe quel type de données dans n'importe quel encodage avec la seule limite de faire moins de 100 kiloBytes. |
||
| + | == Sécurité == |
||
| + | Vient maintenant la question de la sécurité. J’ai trouvé très peu d’informations sur l’utilisation exact des différents capteurs donc du Bluetooth, BLE, du wifi ou encore des ultrasons dans ces différentes API. Google met simplement en avant le fait que les données sont cryptées, et que la proximité des utilisateurs amoindrie considérablement le risque d’attaque. |
||
| − | |||
| + | J’ai donc lu un rapport de l’université d’Oxford qui a tenté de savoir quel était exactement le niveau de sécurité de Nearby Connections. Pour cela ils ont utilisé une technique de reverse engineering. Leur étude a tout d’abord montré que l'API est propriétaire, donc nous n’avons pas accès au code qui fait tourner l’outil. |
||
| − | |||
| + | Leur conclusion a été qu'en l'état actuel, l'API Nearby Connection de Google est non seulement ouverte aux attaques, mais constitue également une menace active pour les nombreux appareils sur lesquels elle est installée puisque les attaquants à proximité n’auraient aucun mal à se connecter à votre terminal. |
||
| − | |||
| + | On pourrait tirer les mêmes conclusions pour Nearby Messages sachant qu’en plus toutes les données circulent dans Google Cloud. |
||
| − | |||
| − | |||
| − | Comme nous pouvons le voir ci-dessus, Apollo a beaucoup évolué en peu de temps. Chaque version a apporté de nouvelle caractéristiques au projet. |
||
| − | En effet, à chaque nouvelle release, des composants hardware sont rajoutés afin d'affiner encore plus la capacité d'analyse de l'environnement. Les contributeurs doivent alors ajouter au projet des modules de code afin de prendre en compte ces nouveaux composants. |
||
| − | |||
| − | '''Apollo 1.0''' |
||
| − | |||
| − | Apollo 1.0 fonctionne dans un lieu clos, comme une piste d'essai ou un parking. |
||
| − | |||
| − | '''Apollo 1.5''' |
||
| − | |||
| − | Avec Apollo 1.5, les véhicules ont une meilleure perception de leur environnement et peuvent mieux cartographier leur position actuelle. Cela leur permet de planifier leur trajectoire sur leur voie. |
||
| − | |||
| − | '''Apollo 2.0''' |
||
| − | |||
| − | Apollo 2.0 permet aux véhicules de rouler de manière autonome sur des routes urbaines simples. Les véhicules sont capables de rouler sur les routes en toute sécurité, d'éviter les collisions avec les obstacles fixes, de s'arrêter aux feux de circulation et de changer de voie. |
||
| − | |||
| − | '''Apollo 2.5''' |
||
| − | |||
| − | Apollo 2.5 permet au véhicule de rouler de manière autonome sur des autoroutes. Les véhicules sont en mesure de maintenir le contrôle de leur voie, de se mettre en vitesse de croisière et d'éviter les collisions avec les véhicules environnants. |
||
| − | |||
| − | '''Apollo 3.0''' |
||
| − | |||
| − | Le but d’Apollo 3.0 est de préparer un environnement pour permettre aux développeurs de travailler sur les espaces à faible vitesse. |
||
| − | |||
| − | '''Apollo 3.5''' |
||
| − | |||
| − | Apollo 3.5 est capable de naviguer dans des scénarios de conduite complexes tels que les zones résidentielles et les centres-villes. |
||
| − | |||
| − | '''Apollo 5.0''' |
||
| − | |||
| − | Avec Apollo 5.0, la voiture peut gérer les conditions changeantes de scénarios routiers complexes. Elle prend en charge des scénarios supplémentaires tels que les arrêts et le franchissement d'intersections dénudées. |
||
| − | |||
| − | == Les avantages de l'Open Source == |
||
| − | |||
| − | En 2017 Baidu a publié Apollo en open-source sous license Apache 2.0. En seulement trois ans, comme l'espérait Baidu, il y a eu beaucoup de contributeurs à la plateforme. |
||
| − | |||
| − | Quelques stats : |
||
| − | |||
| − | - '''8500''' pull requests |
||
| − | |||
| − | - '''15000''' commits |
||
| − | |||
| − | - '''400000''' lignes de code |
||
| − | |||
| − | - '''235''' contributeurs |
||
| − | |||
| − | - '''8''' versions |
||
| − | |||
| − | Le projet est essentiellement codé en C++ et en python pour le module d’Intelligence Artificielle. |
||
| − | |||
| − | == Des Modules rendant plus "intelligent" == |
||
| − | |||
| − | Comme dit précédemment, des modules sont ajoutés à chaque version. Ces modules, destinés à permettre l’autonomie de la voiture, ont été partagés en 7 catégories. |
||
| − | |||
| − | '''Perception de précision''' |
||
| − | |||
| − | Le module de perception intègre la capacité de détecter et de reconnaître les obstacles et les feux de circulation. |
||
| − | |||
| − | ''Obstacle'' |
||
| − | |||
| − | Le sous-module de détection d'obstacles détecte, segmente, classe et suit les obstacles. Il prédit également le mouvement des obstacles et l'information sur leur position (la direction et la vitesse). |
||
| − | |||
| − | ''Feux de circulation'' |
||
| − | |||
| − | Le sous-module de feux de circulation détecte les feux de circulation et reconnaît leur état à partir d’images. |
||
| − | |||
| − | '''Simulation''' |
||
| − | |||
| − | La simulation permet de parcourir virtuellement des millions de kilomètres par jour en utilisant un ensemble de données sur le trafic du monde réel. Grâce au service de simulation, les contributeurs ont accès à un grand nombre de scènes de conduite autonome pour tester, valider et optimiser rapidement des modèles d'intelligence artificielle. |
||
| − | |||
| − | '''Carte Haute Définition et Localisation''' |
||
| − | |||
| − | Baidu est capables de produire des données cartographiques HD à grande échelle. |
||
| − | Ces cartes sont utilisés par le système de localisation. Et ce dernier est une solution de positionnement complète avec une précision au centimètre près. |
||
| − | |||
| − | '''Planification''' |
||
| − | |||
| − | Les véhicules Apollo sont équipés d'un système de planification comprenant la prédiction, le comportement et la logique de mouvement. Le système de planification s'adapte aux conditions de circulation en temps réel, ce qui permet d'obtenir des trajectoires précises, à la fois sûres et confortables. Actuellement, le système de planification fonctionne sur une route fixe dans toutes les conditions de jour comme de nuit. |
||
| − | |||
| − | '''Contrôle Intelligent''' |
||
| − | |||
| − | Les modules Apollo de commande intelligente de véhicule sont précis, largement applicables et adaptables à différents environnements. Les modules gèrent différentes conditions de route, vitesses, et types de véhicules. |
||
| − | |||
| − | |||
| − | == Un véhicule loin d'être standard == |
||
[[File:vueVehicule.png|1000px|thumb|Schéma de la disposition des composants hardwares sur le véhicule]] |
[[File:vueVehicule.png|1000px|thumb|Schéma de la disposition des composants hardwares sur le véhicule]] |
||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | Les caméras, radar et lidar (radar laser) sont utilisés pour la perception de précision. La localisation s'effectue avec les GPS, les LIDARs et la représentation de la carte HD. Pour tout ce qui est des calculs de simulation, de contrôle, de planification ou d’interprétation des données extérieurs, il y a un IMU et un ordinateur industriel dans le coffre. |
||
| − | |||
| − | == Et la Sécurité / CyberSécurité dans tout ça ? == |
||
| − | |||
| − | '''Sécurité de l'IA du véhicule autonome''' |
||
| − | |||
| − | Un système de protection est construit pour protéger la sécurité des applications, des données, de l'IA, des communications et du cloud, et pour empêcher les intrusions externes, les fuites de propriété intellectuelle et le détournement de biens. |
||
| − | |||
| − | '''Communication sécurisée''' |
||
| − | |||
| − | L'IA du véhicule est isolée des autres réseaux. Cela fourni un contrôle pour assurer un accès sécurisé et identifier les comportements anormaux. |
||
| − | |||
| − | '''Boîte noire''' |
||
| − | |||
| − | Un boitier est intégré aux véhicules autonomes. Il enregistre et stocke en toute sécurité les données des capteurs, le mode de conduite, les instructions de planification et de contrôle envoyées à tout le système électronique. Il est utilisé pour les enquêtes sur les accidents et les incidents. |
||
| − | |||
| − | == Une première application : '''Robotaxi''' == |
||
| − | |||
| − | Baidu a lancé en septembre 2019 un service de taxis autonome en Chine. |
||
| − | 45 véhicules électrique ont été équipé avec Apollo. Ces véhicules sont totalement autonome, même si un humain doit être au volant de chaque voiture pour être en conformité avec les réglementations chinoises. |
||
| − | |||
| − | Le système fonctionne par tous temps et peut analyser et voir à plus de 300m. |
||
| − | |||
| − | == Une concurrence forte == |
||
| − | |||
| − | '''Pony.ai ''' |
||
| − | |||
| − | La start-up fondée en décembre 2016 en Californie est focalisée sur le développement des softwares et infrastructures nécessaires pour qu'un véhicule autonome puisse percevoir son environnement, prédire ce que les autres vont faire et manœuvrer en fonction de ces données. |
||
| − | |||
| − | '''Google ''' |
||
| − | |||
| − | La voiture sans conducteur de Google, appelée Google Car, est une voiture autonome en cours de développement. |
||
| − | Deux types de véhicule sont à l'essai : d'une part des véhicules de série modifiés, à l'instar de Toyota Prius, et d'autre part la « Google car », véhicule électrique conçu entièrement par Google sans volant ni commandes d'accélérateur et de frein. |
||
| − | La voiture autonome est autorisée à circuler sur la voie publique dans plusieurs États américains, toujours avec un conducteur derrière le volant pour reprendre le contrôle si nécessaire. |
||
| − | |||
| − | '''Tesla ''' |
||
| − | |||
| − | En octobre 2016, Tesla annonce que ses voitures en production seront désormais équipées en matériel compatible à la conduite 100 % autonome. La partie « software » quant à elle viendra au fur et à mesure des années 2017-2018. |
||
| − | Selon les dernières prévisions de la firme, le FSD (entièrement autonome) devrait être disponible officiellement mi-2020. C’est un grand pas en matière de conduite autonome qui précise les plans de Tesla de lancer une flotte de taxis autonomes dénommés « Robotaxi » en 2020 aux États-Unis avec cette fonction. |
||
| − | |||
| − | '''Mercedes ''' |
||
| − | |||
| − | Mercedes s’est aussi lancé dans le développement de la voiture autonome. Et à vrai dire, la marque à l'hélice n’a pas fait que se lancer, elle est aujourd'hui à fond sur le développement de véhicules sans conducteur. Parmi ses véhicules phares, Mercedes a tenu a présenté sa berline iconique Classe E. |
||
| − | La Classe E est équipée du Drive Pilot qui est une grande innovation dans le domaine de la voiture sans chauffeur. Mercedes a affirmé que cette nouvelle technologie permet au véhicule de circuler en file indienne sur autoroute sans que le chauffeur ait à toucher le volant. Un test a même déjà été fait sur un axe autoroutier autour de Lisbonne. |
||
== Sources == |
== Sources == |
||
Revision as of 15:54, 13 December 2020
Nearby est une plateforme lancée par Google en 2014. Elle est composé de deux API, Nearby Connections et Nearby Messages. Ces API permettent de faciliter la connexion entre des appareils situés à proximité (par exemple de pouvoir s'envoyer un message sans avoir besoin d'un numéro de téléphone).
Description des API
Nearby est en réalité constitué de deux API : Nearby Connections et Nearby Messages. Elles apportent des services similaires mais avec des caractéristiques différentes.
Nearby Connections API
L'API Nearby Connections permet de créer une connexion local entre des appareils à proximité en temps réels. Par exemple, elle rend possible d'associer des appareils et de s'en servir pour des jeux multijoueurs. La connexion est donc limité au réseau local : tous les appareils doivent être sur le même réseau Wifi. La communication n'est possible qu'entre des appareils Android. Son principe de fonctionnement ressemble à une architecture Client-Serveur que nous détaillons plus bas.
Nearby Messages API
L'API Nearby Messages permet plutôt d'envoyer des messages entre appareils, de toute nature mais limité à une certaine taille. Elle rend donc possible des groupes de discussion ou encore la diffusion de ressources. Pour se servir de cette API, les développeur ont besoin de clés API fournies par un compte Google. Les appareils souhaitant communiquer doivent être connectés à internet mais pas nécessairement sur le même réseau Wifi. La communication est possible entre des appareils Android et IOS.
Principe de fonctionnement
Pour permettre cet appariement de proximité, les deux API vont mélanger les avantages et les inconvénients de technologies comme le Wifi, le Bluetooth (standard et BLE), et les ultrasons.
Nearby Connections API
Le principe de fonctionnement de Nearby Connections est assimilable a une architecture Client-Server (OneToMany).
Nearby Messages API
Le principe de fonctionnement de Nearby Messages est assimilable a une architecture ManyToMany. Comme on peut voir sur ce schéma, l'appareil A va envoyer une requête sur Google Cloud pour "s'inscrire" avec un Token (ici TA). Il peut également publier en même temps les données qu'il souhaite diffuser donc ici son nom "iPhone 6" avec le tag "name" (Étape 1). Comme on utilise le Cloud on a besoin des clés API et d'une connexion internet. Pour obtenir ces données, le téléphone B soit "s'abonner" aux données marquées par le tag "name" (Étape 2). L'appareil A va ensuite diffuser son Token aux appareils autour de lui grâce au Bluetooth et aux ultrasons, pendant que l'appareil B va écouter ce qu'il se passe autour de lui (Étape 3) Une fois que B a capté le Token de A, il le signale au Cloud et récupère la donnée correspondante (Étape 4 et 5). On constate donc qu'aucune donnée n'est physiquement échangée entre les deux appareils : tout transite par le Cloud.
Pourquoi utiliser ces moyens de communication ?
Utiliser un mélange de Bluetooth et d'Ultrasons permet de tirer partie des forces de chacun. Les ultrasons communiquent via le haut parleur et le micro des appareils, ils ont une courte fréquence de transmission qui leur permet de ne pas traverser les murs. Et c'est ce qui ressemble à ce que l'utilisateur voudrait : que sa conversation ne sorte pas de la pièce. Mais si les hauts parleurs ou le micro d'un des deux terminal est éteint alors la communication est impossible. C'est pour cela qu'elle est complétée par du Bluetooth. Celui ci est toujours disponible mais a une fréquence d'émission bien trop grande qui permet de traverser les murs. Il y a donc un intérêt à mélanger ces deux modes de communications : la portée des ultrasons et la disponibilité du Bluetooth.
Et au niveau du code ? Pour utiliser l'API Nearby Messages, on a besoin seulement de deux méthodes : publish (pour envoyer des messages) et subscribe (pour les recevoir). Les messages transmis sont des Bytes Array, qui peuvent contenir n'importe quel type de données dans n'importe quel encodage avec la seule limite de faire moins de 100 kiloBytes.
Sécurité
Vient maintenant la question de la sécurité. J’ai trouvé très peu d’informations sur l’utilisation exact des différents capteurs donc du Bluetooth, BLE, du wifi ou encore des ultrasons dans ces différentes API. Google met simplement en avant le fait que les données sont cryptées, et que la proximité des utilisateurs amoindrie considérablement le risque d’attaque. J’ai donc lu un rapport de l’université d’Oxford qui a tenté de savoir quel était exactement le niveau de sécurité de Nearby Connections. Pour cela ils ont utilisé une technique de reverse engineering. Leur étude a tout d’abord montré que l'API est propriétaire, donc nous n’avons pas accès au code qui fait tourner l’outil. Leur conclusion a été qu'en l'état actuel, l'API Nearby Connection de Google est non seulement ouverte aux attaques, mais constitue également une menace active pour les nombreux appareils sur lesquels elle est installée puisque les attaquants à proximité n’auraient aucun mal à se connecter à votre terminal. On pourrait tirer les mêmes conclusions pour Nearby Messages sachant qu’en plus toutes les données circulent dans Google Cloud.
Sources
https://github.com/ApolloAuto/apollo
http://apollo.auto/developer.html
http://apollo.auto/platform/perception.html
http://apollo.auto/platform/simulation.html
http://apollo.auto/platform/security.html
https://fr.wikipedia.org/wiki/Voiture_sans_conducteur_de_Google
https://fr.wikipedia.org/wiki/Tesla_(automobile)