Pour réaliser la communication sans fil pour le système PC portable + PCAN, il faut choisir les technologies sans fil qui soient compatibles avec le CRio+PCAN afin que ces deux confi-gurations puissent communiquer ensemble en utilisant la même technologie de communication. Les technologies de communication sans fil sélectionnées pour notre travail sont le WiFi, la communication radio ZigBee et le GPRS.
L’ensemble des ordinateurs de bureau et notebook intègrent désormais des modules WiFi. Labview permet d’échanger des données avec d’autres systèmes en utilisant des variables par-tagées ou en utilisant des protocoles de communication standards comme le TCP/IP.
Le module XBee 868 PRO, produit par la société DIGI, est un équipement de communi-cation courte portée 868 MHz, fonctionnant dans la bande de fréquences européenne (SRD) G3. Offrant jusqu’à 80 km de portée RF en visibilité directe, ces modules sont parfaitement adaptés aux environnements sans fil complexes, dans lesquels la pénétration RF et la distance de transmission sont primordiales.
Figure II.13 –le module XBee-PRO 868
Les technologies ZigBee et WiFi sont limitées en terme de distance de communication. Elles sont plus adaptées à la communication entre véhicules (V2V). Grâce aux nouvelles technologies comme la 3G, on peut aujourd’hui produire des solutions à faible coût pour une communication sans fil à une longue distance en utilisant les antennes relais des opérateurs téléphoniques et qui disposent d’une couverture optimale. Suivant les caractéristiques de la 3G, l’utilisation de ce type de réseau exige certains types d’architecture et la communication directe entre deux
Chapitre II. Système embarqué sensible au contexte
véhicules et impossible. Dans le cadre de ce projet européen, un prototype avec une architec-ture client / serveur pour la communication sans fil entre un véhicule et une infrastrucarchitec-ture (V2I) ainsi qu’entre les véhicules (V2V) est requis. C’est la raison pour laquelle on utilise un serveur relais qui envoie des messages à une cible donnée. Donc, nous avons implémenté un serveur relais connecté à Internet, nommé RelayServer, pour maintenir la communication avec les véhicules. Les véhicules peuvent communiquer directement avec le RelayServer ou établir une communication en V2V de manière indirecte via le RelayServer. Ce serveur joue le rôle d’un facteur, il reçoit les messages depuis les véhicules pour les relayer aux autres véhicules ou à d’autres serveurs d’application. De plus, les serveurs d’application sont aussi considérés comme des clients, mais ils ont une identité négative qui est différente de celle du véhicule dont l’identité est positive.
Figure II.14 – l’architecture de la communication véhicule
L’architecture proposée pour la communication du véhicule est représentée à la Fig. II.14.
Afin d’assurer les communications entre chaque dispositif, on a utilisé une bibliothèque de
com-munication appelée LibMobileCom (voir la Fig.II.14). Cette bibliothèque fournit une interface
simple pour envoyer et recevoir des messages. Elle utilise les “ sockets " pour garantir la com-munication entre chaque partie de l’architecture. Un Socket est une sorte de point d’ancrage pour les protocoles de transmission de données comme TCP/IP.
LibMobileCom propose une définition d’un régime de socket pour l’échange des messages entre des dispositifs. Ils doivent suivre ce régime de socket qui fournit toutes les informations nécessaires pour envoyer les données requises. Le respect de la structure est nécessaire pour la
II.4 Réalisation du système CAN pervasif
Figure II.15 – Régime de la trame
délivrance d’un message. Le régime de socket est représenté dans la Fig.II.15. Suivant différentes
applications, on peut définir plusieurs types de message comme le message "ABS" qui contient les informations sur le déclenchement d’ABS et la position du véhicule. On peut aussi trouver l’identité de la source et l’identité du destinataire. Bien sur, on peut aussi définir les contenus des données pour le message. Selon la priorité, le serveur RelayServer va garder plus ou moins de mémoire pour le message. Le serveur est développé en langage JAVA afin de réaliser notre conception de l’architecture et le régime de trames. Les clients peuvent être développés en Labview ou en langage JAVA en utilisent les protocoles de communication standards TCP/IP. D’autre part, nous avons réalisé une interface indirecte entre JAVA et Labview.
Figure II.16 – le mécanisme de la communication
Afin d’utiliser la LibMobileCom pour établir une communication entre un client de Labview et le serveur RelayServer, il faut d’abord comprendre le mécanisme de la communication comme
le montre la FigII.16. Nous avons d’abord créé une première connexion GPRS via le port 8383
avec RelayServer pour identifier le client (véhicule). Cette connexion utilise un mode “connecté
" qui est représenté sur la partie gauche de la Fig. II.17. Autrement dit, lorsque le client du
programme Labview envoie son ID, le serveur RelayServer conserve la connexion ouverte tout le temps afin de relayer les messages vers d’autres véhicules. Dans ce cas, la connexion doit être toujours ouverte jusqu’à la fin du programme. Puis on va créer une autre connexion temporaire
Chapitre II. Système embarqué sensible au contexte
pour envoyer des messages vers le serveur RelayServer via le port 8282. Cette connexion utilise
le mode “ déconnecté " représenté sur la partie droite de la Fig.II.17. Ainsi, le serveur va utiliser
la première connexion pour transmettre les données au véhicule de destination.
Figure II.17 –Diagramme de séquence : mode "connecté" et mode “ déconnecté"
Pour avoir la position GPS du véhicule, on a besoin d’un récepteur GPS pour notre PC portable, le récepteur GPS utilisé ici est un Navibe GM720. Il est équipé d’une puce SiRFstar III et d’un connecteur USB. La puce, peu consommatrice d’énergie, peut recevoir des signaux depuis 20 satellites au même moment. La position peut être recalculée toutes les 100 millise-condes. Ce récepteur GPS fonctionne avec le programme Labview ainsi qu’avec le programme en langage JAVA.