FR 3022720 A1 20151225 FR 1462094 A 20141209 DISPOSITIF DE COMMUNICATION EMBARQUÉ POUR UN VÉHICULE AUTOMOBILE La présente invention concerne le domaine de dispositifs de communication embarqués pour des véhicules automobiles. L'arrivée de GPS et de communication de données 5 mobile ces dernières années a changé l'industrie de suivi de flotte automatiquement. Le suivi de flotte comprend le suivi de voitures de location, le suivi de voitures de fonction, et/ou le suivi pour des raisons d'assurance. La technologie ci-dessus a permis le suivi 10 en temps réel de la localisation de voitures équipées, et est à l'origine de nouvelles propositions commerciales. Naturellement, le suivi en temps réel signifie qu'à la fois la localisation en temps réel et la 15 connexion de données en temps réel sont disponibles. Une des problématiques réside dans le fait que de tels dispositifs embarqués constituent typiquement ce qu'on appelle un dispositif M2M (« Machine to Machine » ou communication de machine à machine), qui est un 20 dispositif qui n'a pas d'interaction utilisateur directe, et interagit seulement avec d'autres machines. Ceci pose un problème majeur car cela signifie que les dispositifs doivent être conçus pour empêcher et/ou corriger tout comportement indésirable, 25 particulièrement au cas où des performances en temps réel sont demandées. Afin de garantir un fonctionnement de données correct, les dispositifs M2M établissent et/ou ré- 3022720 2 établissent classiquement un « Contexte PDP » (« Pocket Data Protocol » ou contexte à protocole de données par paquets) pour s'assurer qu'une session de connexion de données est maintenue pour fournir un tuyau de données à un hôte ou à un autre dispositif. De par sa propre nature, une connexion de données sans fil est moins fiable qu'une connexion câblée, essentiellement en raison de brouillage dans le même canal et de trous (ou points noirs) dans la couverture radio. Lorsqu'un dispositif M2M donné n'arrive pas à obtenir un contexte PDP avec son PLMN principal (« Public Land Mobile Network » ou réseau mobile terrestre public), il essaie une itinérance auprès d'un autre PLMN. Dans ce cas, les données transmises par un dispositif en itinérance sur un PLMN étranger devront subir une tunnellisation à travers diverses interconnexions différentes pour arriver à son GGSN désigné (« Gateway GPRS Support Node » ou noeud de support GPRS de transit) à son PLMN domestique. Ceci constitue une transmission de données complexe, impliquant des équipements de différents fabricants à travers plusieurs frontières géographiques. Dans de tels cas, il est courant pour des dispositifs à objectif d'itinérance de garantir un contexte PDP et cependant de ne pas être capables de transmettre des données à leur destination avec succès. Les seuls procédés connus dépendent du réamorçage du modem lorsqu'il n'arrive pas à s'authentifier auprès 30 d'un PLMN donné ou s'il n'arrive pas à obtenir une session de données GSM. Cependant, si le problème 3022720 3 susmentionné se produit, il y a un risque de réaliser un réamorçage répété du modem sur une courte fenêtre de temps, ce qui peut avoir pour résultat le fait que le PLMN prend des mesures pour mettre sur liste noire le 5 dispositif M2M. L'objectif de l'invention est d'améliorer la situation en proposant un dispositif de communication embarqué pour un véhicule automobile comprenant un contrôleur et un modem GSM, dans lequel ledit 10 contrôleur est agencé pour surveiller des données passant à travers le modem, pour sélectionner des échanges de données impliquant des données de retour au dispositif, pour analyser des échanges de données sélectionnés, et pour réamorcer sélectivement le modem 15 auprès d'un nouveau fournisseur de services en fonction de ladite analyse. Dans la présente demande, les termes modem GSM comprennent généralement des modems GPRS, EDGE, 3G ou 4G. 20 Selon des aspects supplémentaires, le dispositif embarqué peut comprendre en outre les caractéristiques suivantes : - le contrôleur est agencé pour incrémenter un compteur d'erreur lorsque des données de retour ne sont 25 pas reçues dans un temps seuil pour un échange de données donné, et pour entraîner un réamorçage du modem auprès d'un nouveau fournisseur de services en fonction du nombre de réamorçages auprès d'un fournisseur de services actuel, - ledit contrôleur est agencé pour incrémenter un compteur de réamorçage pour un fournisseur de services 3022720 4 actuel lors de l'entraînement d'un réamorçage du modem, ledit contrôleur étant en outre agencé pour entraîner un réamorçage du modem auprès d'un nouveau fournisseur de services si le compteur de réamorçage dépasse le 5 seuil de réamorçage, et autrement pour entraîner un réamorçage du modem auprès d'un fournisseur de services actuel, - le contrôleur est en outre agencé pour réaliser un réamorçage du modem auprès d'un fournisseur de 10 services actuel après expiration d'un temps mort aléatoire, - le contrôleur est agencé pour démarrer un minuteur d'itinérance lors d'un premier réamorçage du modem auprès d'un nouveau fournisseur de services, pour 15 réamorcer le modem auprès d'un fournisseur de services favori lors de l'expiration dudit minuteur d'itinérance, et pour remettre à zéro ledit minuteur d'itinérance lors d'une reconnexion du modem à un fournisseur de services favori. 20 - le modem GSM est compatible avec un ou plusieurs parmi un réseau GPRS, EDGE, 3G et 4G. D'autres caractéristiques et avantages de l'invention apparaîtront à la lecture de la description suivante, qui est tirée d'exemples illustratifs et non 25 limitatifs basés sur les dessins sur lesquels : - la figure 1 représente une vue schématique d'un dispositif embarqué pour un véhicule automobile selon l'invention, - la figure 2 représente un organigramme 30 illustratif d'une fonction de contrôle de modem réalisée par le dispositif de la figure 1, 3022720 5 - les figures 3 et 4 représentent des modes de réalisation illustratifs de fonctions de la figure 2, et - les figures 5 à 7 représentent des fonctions 5 illustratives de la figure 2 selon un second mode de réalisation de l'invention. Les dessins et la description suivante comprennent, pour l'essentiel, des éléments qui définissent positivement les modes de réalisation. Par conséquent, 10 ils peuvent être utilisés à la fois dans le but d'améliorer la compréhension de l'invention, mais également dans le but de la définir, si cela est nécessaire. La figure 1 représente une vue schématique d'un 15 dispositif embarqué 2 pour un véhicule automobile selon l'invention. Dans l'exemple décrit ici, ce dispositif est un dispositif de suivi de flotte GPS. Cependant, on comprendra que l'invention peut s'appliquer à tout dispositif M2M en général. 20 Le dispositif embarqué 2 comprend un contrôleur 4, un module GPS 6, et un modem 8. Le contrôleur 4 est agencé pour contrôler à la fois le module GPS 6 et le modem 8 pour fournir le suivi en temps réel d'un véhicule dans lequel le 25 dispositif 2 est installé. Plus précisément, le contrôleur 4 contrôle l'état du module GPS 6, ainsi que les données qui sont acquises par celui-ci. Le contrôleur 4 contrôle en outre le fonctionnement du modem 8. Le modem 8 comprend 30 son propre microprogramme pour le fonctionnement avec un réseau GSM, qui, comme cela est défini ci-dessus, 3022720 6 comprend des réseaux GPRS, EDGE, 3G ou 4G, et peut également recevoir des commandes à partir du contrôleur 4 par l'intermédiaire d'une interface qui est appelée connecteur logiciel (socket). En d'autres 5 termes, le modem est agencé pour fonctionner par lui- même pour réaliser des transferts de données en fonction de commandes reçues à partir du contrôleur 4, mais il peut également recevoir des commandes telles que des commandes de réamorçage auprès d'un PLMN 10 spécifique à partir du contrôleur 4, et le modem 8 peut fonctionner sur un ou plusieurs parmi un réseau GPRS, EDGE, 3G et 4G. La figure 2 représente un organigramme d'une fonction de contrôle modèle réalisée par le 15 contrôleur 4. Lors de l'amorçage initial du dispositif, le contrôleur 4 lance une fonction Dev Boot Up() dans une opération 200. Lors d'un achèvement de cette fonction, une boucle 20 est commencée dans laquelle le contrôleur 4 surveille toutes les transmissions de données envoyées par l'intermédiaire du modem 8, et la répète sélectivement jusqu'à ce que le dispositif soit éteint. Dans une opération 210, une fonction Frst Boot() 25 est réalisée, dont un mode de réalisation va être décrit avec la figure 3. Comme cela est représenté sur la figure 3, la fonction Frst Boot() commence avec une opération 300 dans laquelle le contrôleur 4 vérifie si le modem a été réamorcé depuis l'allumage de dispositif, 30 ou s'il s'agit du premier amorçage après que le dispositif a été éteint. 3022720 7 Si le dispositif vient juste de s'allumer et le modem n'a pas encore été amorcé, une variable PLMN cntr est initialisée avec la valeur 0 dans une opération 310. Après cela, dans une opération 320, une variable 5 PLMN rm t est initialisée avec la valeur 0. Après l'opération 320, ou si le modem a déjà été amorcé, la fonction Frst Boot() se termine dans une opération 330. Après la fin de la fonction Frst Boot(), le contrôleur 4 exécute une fonction Roam Chck() dans une 10 opération 220. La figure 4 représente un mode de réalisation illustratif de la fonction Roam Chck(). La fonction Roam Chck() est réalisée pour limiter le temps d'itinérance autant que possible. Dans une opération 400, le contrôleur 4 vérifie si 15 une quelconque itinérance a été réalisée jusqu'à présent. Si ceci n'est pas le cas, alors la fonction se termine immédiatement avec l'opération 410. Autrement, une variable rm est calculée dans une opération 420. La 20 variable rm est définie comme étant la différence entre l'instant actuel (obtenu par l'intermédiaire de la fonction Tim()) et la variable PLMN rm t (qui contient l'instant auquel l'itinérance a commencé). La variable rm est ainsi une indication de la quantité de temps qui 25 s'est écoulée depuis que le dispositif a commencé l'itinérance. La variable rm est alors comparée à un seuil d'itinérance rm thrsh dans une opération 430. Le seuil d'itinérance rm thrsh représente la quantité maximum de 30 temps après laquelle l'essai et l'arrêt de l'itinérance sont souhaités. 3022720 8 Si la variable rm dépasse le seuil d'itinérance rm thrsh, alors la variable PLMN cntr est remise à 0 afin de retourner au PLMN principal dans une opération 440, et la variable PLMN rm t est remise à 0 5 dans une opération 450, avant la fin de la fonction Roam Chck() dans l'opération 410. Autrement, une fonction Bckg Tmo() est appelée avec la différence entre variable rm et le seuil d'itinérance rm thrsh dans une opération 460. La fonction Bckg Tmo() lance un 10 minuteur en arrière-plan et passe à l'opération 910. Lors de l'expiration du minuteur en arrière-plan, une interruption bloque toute expiration d'opération actuelle, et réalise les opérations 440 et 450. L'opération 460 est facultative, et garantit que 15 l'itinérance est toujours limitée sur un PLMN d'itinérance continuellement fonctionnel. Après que l'opération 220 se termine, le contrôleur 4 amorce le modem auprès du PLMN actuellement sélectionné dans une opération 230, au 20 moyen de la fonction Wrt Sckt(), qui utilise la variable PLMN cntr. La variable PLMN cntr désigne le PLMN souhaité auprès duquel l'amorçage doit se faire. Afin de faire cela, le contrôleur 4 écrit des données de réamorçage dans le connecteur logiciel de modem. 25 Par exemple, la liste de PLMN disponibles est indexée dans le modem, le PLMN principal (celui sans itinérance) étant le premier, avec l'indice 0. Lorsque le modem reçoit au niveau du connecteur logiciel la variable PLMN cntr à partir de la fonction Wrt Sckt(), 30 il se réamorce auprès du fournisseur de services qui est désigné par la variable PLMN cntr. Ainsi, au tout 3022720 9 premier amorçage du dispositif, le modem est amorcé auprès du PLMN principal. Si la variable PLMN cntr est incrémentée, alors le modem s'amorce auprès du PLMN indexé suivant, etc. 5 Après que le modem est amorcé auprès du fournisseur de services désigné, le contrôleur 4 réalise une fonction Monit() dans une opération 240. Dans ce mode de réalisation, la fonction Monit() vérifie que la session de données est active, à savoir 10 que la connexion de données est fonctionnelle. Monit() est une boucle qui se termine lorsqu'il est détecté que la connexion a été perdue. Lorsque la fonction Monit() détecte que la session de données ne fonctionne plus, le contrôleur 4 exécute 15 une fonction Reboot(), qui est réalisée dans une opération 250. La figure 4 représente un mode de réalisation illustratif de la fonction Reboot(). Dans ce mode de réalisation, la fonction Reboot() modifie la variable PLMN rm t de sorte qu'elle stocke l'instant 20 auquel la fonction Monit() s'est terminée. Après cela, la fonction Reboot() recommence la fonction de contrôle modèle à l'opération 210. Les figures 5 à 7 représentent des fonctions illustratives d'un autre mode de réalisation qui est 25 plus sophistiqué. La figure 5 représente une variante de la fonction Frst Boot(). Dans ce mode de réalisation, la fonction Frst Boot() est la même que celle de la figure 3, à l'exception qu'une variable supplémentaire reb cntr est 30 initialisée avec la valeur 0 dans une opération 500. 3022720 10 La figure 6 représente un mode de réalisation illustratif d'une variante de la fonction Monit(). Dans une opération 600, une variable err cntr est initialisée avec la valeur 0. Après cette opération, 5 une boucle est réalisée dans une opération 610 avec une fonction Mon OutDat(). La fonction Mon OutDat() exécutée par le contrôleur 4 surveille toutes les données étant envoyées par l'intermédiaire du modem pour vérifier si des données de retour sont attendues, 10 par exemple sous forme d'accusé de réception ou autre. L'opération 610 se boucle sur elle-même jusqu'à ce que la fonction Mon OutDat() détecte un échange de données impliquant des données de retour attendues. Lorsqu'un tel échange de données est détecté, une 15 fonction Tmo() est réalisée dans une opération 620. La fonction Tmo() attend pendant un temps prédéterminé qui est attribué pour recevoir les données de retour attendues. Après que la fonction Tmo() s'est terminée, une fonction Ack() qui vérifie si les données de retour 20 ont été reçues est réalisée dans une opération 630. Si des données de retour ont été reçues, ceci signifie que la connexion de données semble fonctionner et la fonction Monit() est recommencée à l'opération 600, et la variable err cntr est remise à 0. 25 Si aucunes données de retour n'ont été reçues, alors la variable err cntr est incrémentée dans une opération 640. Enfin, dans une opération 650, la variable err cntr est comparée à un seuil d'erreur err thrsh 30 pour vérifier si trop de données de retour ont été successivement manquantes. Si c'est le cas, alors la 3022720 11 fonction Monit() se termine dans une opération 660. Autrement, la fonction Monit() continue la boucle 610 pour une surveillance supplémentaire. La fonction Monit() est prévue pour être 5 massivement parallèle. Ceci signifie qu'à chaque fois qu'un échange de données impliquant des données de retour est détecté par la fonction Mon OutDat(), un minuteur séparé est commencé par la fonction Tmo(), et, lorsque ce minuteur expire, il est vérifié si les 10 données de retour ont été reçues ou non. Dans un autre mode de réalisation, les opérations 620 et 630 peuvent être fusionnées, et la fonction Tmo() de l'opération 620 peut comprendre une opération d'interruption. Dans ce cas, la fonction Tmo() 15 vérifie régulièrement si les données de retour ont été reçues. Lors de la détection, à savoir lorsque des données de retour ont été reçues, la fonction Tmo() réalise une interruption de toutes les fonctions Tmo() exécutées en parallèle, et la fonction Monit() retourne 20 à l'opération 600. Si aucune interruption ne se produit durant le temps attribué par une fonction Tmo() donnée, alors la fonction Monit() passe à l'opération 640. Lorsque la fonction Monit() se termine, ceci signifie que le nombre d'erreurs détectées avec la 25 variable err cntr dépasse le seuil d'erreur err trsh. En d'autres termes, le nombre de retours de données attendus qui ont été détectés comme non reçus par la fonction Monit(), est considéré comme signifiant qu'il y a un problème avec la connexion de données. 30 La figure 7 représente un mode de réalisation illustratif d'une autre fonction Reboot(). 3022720 12 Dans une opération 700, la variable reb cntr est incrémentée. Après cela, un test est réalisé dans une opération 710 pour vérifier si la variable rb cntr dépasse un seuil de réamorçage rb thrsh. Si c'est le 5 cas, ceci signifie que le PLMN actuel désigné par la variable PLMN cntr est indisponible pour une connexion de données, et qu'il est préférable de réamorcer le modem auprès d'un nouveau PLMN. Par conséquent, la variable rb cntr est remise à 10 la valeur 0 dans une opération 720, et la variable PLMN cntr est incrémentée dans une opération 730. Si le seuil de réamorçage n'est pas dépassé, alors une fonction facultative Tmo(rdm) est réalisée dans une opération 740. Cette fonction attend pendant une 15 quantité de temps aléatoire, ce qui peut être utile avec certains PLMNs qui mettent sur liste noire des dispositifs qui se réamorcent à des intervalles réguliers. L'opération 740 peut, en variante, être omise. 20 Après l'opération 740, la fonction Wrt Sckt() est appelée à nouveau dans une opération 750, comme dans l'opération 220, afin de réamorcer le modem auprès du PLMN désigné par la variable PLMN cntr, et la fonction de contrôle de modem est mise en boucle à 25 l'opération 210. Après l'opération 730, une opération 760 est réalisée lorsque la variable rb err dépasse le seuil de réamorçage rb thrsh. Dans l'opération 760, la variable PLMN rm t est comparée à 0. En cas d'égalité, alors 30 ceci signifie qu'aucune itinérance n'a été réalisée jusqu'à présent, et la variable PLMN rm t est 3022720 13 actualisée avec le temps actuel dans l'opération 770 au moyen de la fonction Tim(). En plus de l'opération 770, ou si une itinérance se produit déjà, la fonction Reboot() se termine avec l'opération 750, comme cela 5 est décrit ci-avant. Dans ce qui précède, certaines des opérations décrites peuvent être réalisées en parallèle ou en série, ou réalisées d'une autre manière qui apparaîtra facilement à l'homme du métier. Ces autres possibilités 10 sont toutes incluses dans la portée des revendications suivantes. Bien que la présente invention ait été généralement décrite pour s'occuper d'itinérance, de pannes de connexion et de délais d'attente de connexion, 15 il vaut la peine de noter qu'elle peut également s'appliquer avantageusement à d'autres problèmes spécifiques. Par exemple, la présente invention peut aider le système à s'occuper d'un fournisseur qui ne fournit pas 20 le service demandé (par exemple un fournisseur offrant un transfert de voix mais qui n'offre pas de transfert de données). De manière plus générale, la présente invention peut permettre au système de s'occuper de fournisseurs 25 en fonction d'un ou de plusieurs critères, à savoir, par exemple, de la disponibilité et des services fournis, mais également des frais. Dans ce but, le dispositif embarqué peut comprendre une liste de fournisseurs et l'invention se 30 chargera du routage vers des fournisseurs préférés en 3022720 14 fonction des critères susmentionnés et selon la liste de fournisseurs. Bien entendu, l'invention n'est pas limitée aux exemples de réalisation ci-dessus décrits et 5 représentés, à partir desquels on pourra prévoir d'autres modes et d'autres formes de réalisation, sans pour autant sortir du cadre de l'invention. REVENDICATIONS1. Dispositif de communication embarqué (2) pour un véhicule automobile comprenant un contrôleur (4) et un modem GSM (8), dans lequel ledit contrôleur (4) est agencé pour démarrer un minuteur d'itinérance lors d'un 5 premier réamorçage du modem (8) auprès d'un nouveau fournisseur de services GSM, pour réamorcer le modem (8) auprès d'un fournisseur de services GSM favori lors de l'expiration dudit minuteur d'itinérance, et pour remettre à zéro ledit minuteur d'itinérance lors d'une 10 reconnexion du modem (8) à un fournisseur de services GSM favori. 2. Dispositif de communication embarqué (2) selon la revendication 1, dans lequel le contrôleur (4) est en outre agencé pour surveiller des données passant à 15 travers le modem (8), pour sélectionner des échanges de données impliquant des données de retour au dispositif (2), pour analyser des échanges de données sélectionnés, et pour réamorcer sélectivement le modem (8) auprès d'un nouveau fournisseur de services 20 GSM en fonction de ladite analyse. 3. Dispositif de communication embarqué (2) selon la revendication 2, dans lequel ledit contrôleur (4) est agencé pour incrémenter un compteur d'erreur lorsque des données de retour ne sont pas reçues dans 25 un temps seuil pour un échange de données donné, et pour entraîner un réamorçage du modem (8) auprès d'un nouveau fournisseur de services GSM en fonction du nombre de réamorçages auprès d'un fournisseur de services actuel. 3022720 16 4. Dispositif de communication embarqué (2) selon la revendication 3, dans lequel ledit contrôleur (4) est agencé pour incrémenter un compteur de réamorçage pour un fournisseur de services actuel lors de 5 l'entraînement d'un réamorçage du modem (8), ledit contrôleur (4) étant en outre agencé pour entraîner un réamorçage du modem (8) auprès d'un nouveau fournisseur de services GSM si le compteur de réamorçage dépasse le seuil de réamorçage, et autrement pour entraîner un 10 réamorçage du modem (8) auprès d'un fournisseur de services actuel. 5. Dispositif de communication embarqué (2) selon la revendication 4, dans lequel le contrôleur (4) est agencé pour réaliser un réamorçage du modem (8) auprès 15 d'un fournisseur de services actuel après expiration d'un temps mort aléatoire. 6. Dispositif de communication embarqué (2) selon une des revendications précédentes, dans lequel ledit modem GSM est compatible avec un ou plusieurs parmi un 20 réseau GPRS, EDGE, 3G et 4G.