FR 3022719 A1 20151225 FR 1462092 A 20141209 DISPOSITIF DE COMMUNICATION EMBARQUÉ POUR UN VÉHICULE AUTOMOBILE La présente invention concerne le domaine des dispositifs de communication embarqués pour des véhicules automobiles. L'arrivée du GPS et de la 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 ceci 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 convoitées. Afin de garantir un fonctionnement de données correct, les dispositifs M2M établissent classiquement 3022719 2 et/ou ré-établissent 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 en raison essentiellement 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 d'un PLMN donné ou s'il n'arrive pas à obtenir une session de données GSM. Cependant, si le problème susmentionné se produit, il y a un risque de réaliser 3022719 3 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 dispositif M2M. 5 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 contrôleur est agencé pour surveiller des données 10 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 auprès d'un nouveau fournisseur de services en fonction 15 de ladite analyse. Dans la présente demande, les termes modem GSM comprennent généralement des modems GPRS, EDGE, 3G ou 4G. Selon des aspects supplémentaires, le dispositif 20 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 pas reçues dans un temps seuil pour un échange de 25 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 30 compteur de réamorçage pour un fournisseur de services actuel lors de l'entraînement d'un réamorçage du modem, 3022719 4 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 seuil de réamorçage, et autrement pour entraîner un 5 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 services actuel après expiration d'un temps mort 10 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 réamorcer le modem auprès d'un fournisseur de services 15 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, - le modem GSM est compatible avec un ou plusieurs 20 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 limitatifs basés sur les dessins sur lesquels : 25 - 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 illustratif d'une fonction de contrôle de modem 30 réalisée par le dispositif de la figure 1, 3022719 5 - les figures 3 à 5 représentent des modes de réalisation illustratifs de fonctions de la figure 2, - la figure 6 représente une variante de fonction de contrôle de modem, et 5 - les figures 7 à 9 représentent des modes de réalisation illustratifs de fonctions de la figure 6. 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, 3022719 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. 3022719 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, une variable reb cntr est initialisée avec 5 la valeur 0 dans une opération 320. 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 amorce le modem auprès du PLMN 10 actuellement sélectionné dans une opération 220, au 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 15 de réamorçage dans le connecteur logiciel de modem. Par exemple, la liste de PLMNs 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 20 variable PLMN cntr à partir de la fonction Wrt Sckt(), il se réamorce auprès du fournisseur de services qui est désigné par la variable PLMN cntr. Ainsi, au tout premier amorçage du dispositif, le modem est amorcé auprès du PLMN principal. Si la variable PLMN cntr est 25 incrémentée, alors le modem s'amorce auprès du PLMN indexé suivant, etc. 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 230. 30 La figure 4 représente un mode de réalisation illustratif de la fonction Monit(). 3022719 8 Dans une opération 400, une variable err cntr est initialisée avec la valeur 0. Après cette opération, une boucle est réalisée dans une opération 410 avec une fonction Mon OutDat(). La fonction Mon OutDat() 5 exécutée par le contrôleur 4 surveille toutes les données envoyées par l'intermédiaire du modem pour vérifier si des données de retour sont attendues, par exemple sous forme d'accusé de réception ou autre. L'opération 410 se boucle sur elle-même jusqu'à ce que 10 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 fonction Tmo() est réalisée dans une opération 420. La fonction Tmo() attend pendant un temps prédéterminé qui 15 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 ont été reçues est réalisée dans une opération 430. Si des données de retour ont été reçues, ceci 20 signifie que la connexion de données semble fonctionner et la fonction Monit() est réinitialisée à l'opération 400, et la variable err cntr est remise à 0. Si aucune donnée de retour n'a été reçue, alors la variable err cntr est incrémentée dans une 25 opération 440. Enfin, dans une opération 450, la variable err cntr est comparée à un seuil d'erreur err thrsh pour vérifier si trop de données de retour ont été successivement manquantes. Si c'est le cas, alors la 30 fonction Monit() se termine dans une opération 460. 3022719 9 Autrement, la fonction Monit() continue la boucle 410 pour une surveillance supplémentaire. La fonction Monit() est prévue pour être massivement parallèle. Ceci signifie qu'à chaque fois 5 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 données de retour ont été reçues ou non. 10 Dans un autre mode de réalisation, les opérations 420 et 430 peuvent être fusionnées, et la fonction Tmo() de l'opération 420 peut comprendre une opération d'interruption. Dans ce cas, la fonction Tmo() vérifie régulièrement si les données de retour ont été 15 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 à l'opération 400. Si aucune interruption ne se produit 20 durant le temps attribué par une fonction Tmo() donnée, alors la fonction Monit() passe à l'opération 440. Lorsque la fonction Monit() se termine, ceci signifie que le nombre d'erreurs détectées avec la variable err cntr dépasse le seuil d'erreur err trsh. 25 En d'autres termes, le nombre de retours de données attendus qui ont été détectés comme n'étant pas reçus par la fonction Monit() de l'opération 230 est considéré comme signifiant qu'il y a un problème avec la connexion de données. Après cela, une fonction 30 Reboot() est réalisée dans une opération 240. 3022719 10 La figure 5 représente un mode de réalisation illustratif de la fonction Reboot(). Dans une opération 500, la variable reb cntr est incrémentée. Après cela, un test est réalisé dans une 5 opération 510 pour vérifier si la variable rb cntr dépasse un seuil de réamorçage rb thrsh. Si c'est le 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 10 modem auprès d'un nouveau PLMN. Par conséquent, la variable rb cntr est remise à la valeur 0 dans une opération 520, et la variable PLMN cntr est incrémentée dans une opération 530. Si le seuil de réamorçage n'est pas dépassé, alors une 15 fonction facultative Tmo(rdm) est réalisée dans une opération 540. Cette fonction attend pendant une 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 20 réguliers. L'opération 540 peut, en variante, être omise. Après l'opération 530 ou 540, la fonction Wrt Sckt() est appelée à nouveau, 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 25 de contrôle de modem est mise en boucle à l'opération 210. La figure 6 représente un autre mode de réalisation de la fonction de contrôle de modem de la figure 2. Cette fonction est essentiellement la même, à 30 l'exception qu'une opération supplémentaire 600 a été ajoutée, dans laquelle une fonction Roam Chck() vérifie 3022719 11 et limite le temps en itinérance. La fonction Roam Chck() va être décrite avec la figure 9. Une nouvelle opération 600 est réalisée entre les opérations 210 et 220. 5 Afin de prendre en compte l'opération 600, la fonction Frst Boot() de l'opération 210 a été légèrement modifiée, comme cela est représenté sur la figure 7. La modification se trouve dans l'ajout de la nouvelle opération 700, qui initialise une variable 10 PLMN rm t avec la valeur 0. Afin de prendre en compte l'opération 600, la fonction Reboot() de l'opération 240 a également été légèrement modifiée, comme cela est représenté sur la figure 8. La modification se trouve dans l'ajout des 15 nouvelles opérations 800 et 810. L'opération 800 est réalisée après l'opération 530, lorsque la variable rb err dépasse le seuil de réamorçage rb thrsh. Dans l'opération 800, la variable PLMN rm t est comparée à 0. En cas d'égalité, alors ceci signifie qu'aucune 20 itinérance n'a été réalisée jusqu'à présent, et la variable PLMN rm t est actualisée avec le temps actuel dans l'opération 810 au moyen de la fonction Tim(). En plus de l'opération 810, ou si une itinérance se produit déjà, la fonction Reboot() se termine avec 25 l'opération 550, comme cela est décrit ci-avant. La figure 9 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. 3022719 12 Dans une opération 900, le contrôleur 4 vérifie si une quelconque itinérance a été réalisée jusqu'à présent, comme dans l'opération 800. Si ceci n'est pas le cas, alors la fonction se 5 termine immédiatement avec l'opération 910. Autrement, une variable rm est calculée dans une opération 920. La 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 10 l'instant auquel l'itinérance a commencé). La variable rm est ainsi une indication de la quantité de temps qui s'est écoulée depuis que le dispositif a commencé l'itinérance. La variable rm est alors comparée à un seuil 15 d'itinérance rm thrsh dans une opération 930. Le seuil d'itinérance rm thrsh représente la quantité maximum de temps après laquelle l'essai et l'arrêt de l'itinérance sont souhaités. Si la variable rm dépasse le seuil d'itinérance 20 rm thrsh, alors la variable PLMN cntr est remise à 0 afin de retourner au PLMN principal dans une opération 940, et la variable PLMN rm t est remise à 0 dans une opération 950, avant la fin de la fonction Roam Chck() dans l'opération 910. Autrement, une 25 fonction Bckg Tmo() est appelée avec la différence entre la variable rm et le seuil d'itinérance rm thrsh dans une opération 960. La fonction Bckg Tmo() lance un minuteur en arrière-plan et passe à l'opération 910. Lors de l'expiration du minuteur en arrière-plan, une 30 interruption bloque toute expiration d'opération actuelle, et réalise les opérations 940 et 950. 3022719 13 L'opération 960 est facultative, et garantit que l'itinérance est toujours limitée sur un PLMN d'itinérance continuellement fonctionnel. Dans ce qui précède, certaines des opérations 5 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 sont toutes incluses dans la portée des revendications suivantes. 10 Bien que la présente invention ait été généralement décrite pour s'occuper de pannes de connexion et de délais d'attente de connexion, il n'est pas inutile de préciser qu'elle peut également s'appliquer avantageusement à d'autres problèmes 15 spécifiques. Par exemple, la présente invention peut aider le système à s'occuper d'un fournisseur qui ne fournit pas le service demandé (par exemple un fournisseur offrant un transfert de voix mais qui n'offre pas de transfert 20 de données). Plus généralement, la présente invention peut permettre au système de s'occuper de fournisseurs en fonction d'un ou de plusieurs critères, à savoir, par exemple, de la disponibilité et des services fournis, 25 mais également des frais. Dans ce but, le dispositif embarqué peut comprendre une liste de fournisseurs et l'invention se chargera du routage vers des fournisseurs préférés en fonction des critères susmentionnés et selon la liste 30 de fournisseurs. 3022719 14 Bien entendu, l'invention n'est pas limitée aux exemples de réalisation ci-dessus décrits et représentés, à partir desquels on pourra prévoir d'autres modes et d'autres formes de réalisation, sans 5 pour autant sortir du cadre de l'invention. REVENDICATIONS1. Dispositif de communication embarqué pour un véhicule automobile comprenant un contrôleur (4) et un modem GSM (8), dans lequel ledit contrôleur (4) est agencé pour surveiller des données passant à travers le modem (8), 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 (8) auprès d'un nouveau fournisseur de services en fonction de ladite 10 analyse. 2. Dispositif de communication embarqué selon la revendication 1, 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 un temps 15 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 en fonction du nombre de réamorçages auprès d'un fournisseur de services actuel. 20 3. Dispositif de communication embarqué selon la revendication 2, 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 l'entraînement d'un réamorçage du modem (8), ledit 25 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 si le compteur de réamorçage dépasse le seuil de réamorçage, et autrement pour entraîner un 3022719 16 réamorçage du modem (8) auprès d'un fournisseur de services actuel. 4. Dispositif de communication embarqué selon la revendication 3, dans lequel le contrôleur (4) est 5 agencé pour réaliser un réamorçage du modem (8) auprès d'un fournisseur de services actuel après expiration d'un temps mort aléatoire. 5. Dispositif de communication embarqué selon une des revendications précédentes, dans lequel le contrôleur (4) est agencé pour démarrer un minuteur d'itinérance lors d'un premier réamorçage du modem (8) auprès d'un nouveau fournisseur de services, pour réamorcer le modem (8) 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 (8) à un fournisseur de services favori. 6. Dispositif de communication embarqué selon une des revendications précédentes, dans lequel ledit modem 20 GSM est compatible avec un ou plusieurs parmi un réseau GPRS, EDGE, 3G et 4G.