FR2861945A1 - Procede d'analyse du fonctionnement d'un terminal de radiocommunication, terminal de radiocommunication et dispositif d'analyse correspondants - Google Patents

Abstract

L'invention concerne un procédé d'analyse du fonctionnement d'un terminal de radiocommunication (12) selon un protocole de radiocommunication prédéterminé, selon lequel ledit terminal de radiocommunication (12) transmet des données représentatives d'au moins une opération à analyser vers un dispositif d'analyse distant (11), via une liaison (14) selon ledit protocole de radiocommunication prédéterminé.

Description

Procédé d'analyse du fonctionnement d'un terminal de radiocommunication,

terminal de radiocommunication et dispositif d'analyse correspondants.

Le domaine de l'invention est celui du contrôle et de l'analyse du fonctionnement de dispositifs de radiocommunication, tels que des radiotéléphones ou des terminaux équipés de moyens de radiocommunication (installés par exemple dans des machines, des capteurs, des automobiles,.. .).

D'une façon générale, les produits électroniques sont testés de la façon la plus exhaustive possible, avant leur mise sur le marché. Cependant, la complexité de ces appareils augmente régulièrement, et il apparaît très difficile de les tester intégralement, et d'identifier toutes les situations auxquelles ils peuvent être confrontés.

Ceci est notamment dû au fait qu'ils embarquent des moyens logiciels importants et complexes, et qu'ils peuvent être confrontés à de très nombreuses 15 situations et applications.

C'est notamment le cas dans le domaine des radiocommunications. Les constructeurs de moyens de radiotéléphonie et les opérateurs sont donc contraints de diffuser des produits qui peuvent encore présenter certains défauts logiciels ( bugs en anglais) qui n'ont pas été identifiés, par exemple parce qu'ils correspondent à des circonstances très spécifiques, très rares ou très difficiles à anticiper et à reproduire.

De tels bugs peuvent par exemple être liés à : des caractéristiques du réseau (cellules voisines, niveaux, ...) ; à la carte SIM (par exemple nombre d e messages SMS) ; - à l'environnement matériel (niveau de la batterie, éléments périphériques, ...) ; aux actions de l'utilisateur (navigation dans les menus, utilisation d'applications spécifiques WAP, SMS, MMS, JAVA, ...).

Bien que l'on mette en oeuvre des simulateurs et des émulateurs pour tenter 30 d'identifier ces défauts, et y remédier, il peut toujours rester des situations dans lesquelles le dispositif de radiocommunication ne réagit pas comme il devrait. Il est alors nécessaire d'étudier le fonctionnement de ce dispositif, afin d'identifier l'origine du défaut, et le cas échéant d'effectuer les corrections nécessaires.

Pour effectuer ces opérations, on utilise généralement des appareils de mesure et de test, tels que des analyseurs de protocole, qui sont capables d'observer et d'analyser les échanges de données effectués selon les protocoles utilisés par le dispositif de radiocommunication.

Cette technique est efficace, mais souvent peu aisée à mettre en oeuvre, puisqu'elle suppose d'avoir à proximité un appareillage complexe. Lorsque 10 l'appareil défaillant est un radiotéléphone, il faut donc que l'utilisateur le renvoie vers un laboratoire de test, après avoir expliqué le plus précisément possible le défaut identifié et les conditions dans lesquelles il apparaît. Il s'agit d'une démarche peu aisée, et qui prive l'utilisateur de son radiotéléphone pendant plusieurs jours voire plusieurs semaines. Il existe en outre un risque important que 15 le défaut ne soit pas bien identifié, si la description du problème est erronée ou incomplète.

Lorsqu'il s'agit de moyens de radiotéléphonie installés dans des machines, il faut soit les démonter pour les renvoyer vers un laboratoire, soit se déplacer sur site avec le matériel de test. A nouveau, on comprend que, dans les deux 20 situations, cela est complexe, et coûteux, tant en temps que financièrement.

L'invention a notamment pour objectif de pallier ces différents inconvénients de l'état de l'art.

Plus précisément, un objectif de l'invention est de fournir une technique ne nécessitant pas l'envoi du dispositif défaillant vers un site distant, ni le 25 déplacement d'un spécialiste avec son matériel de test.

En d'autres termes, un objectif de l'invention est de fournir une technique permettant d'effectuer l'analyse d'un défaut, et le cas échéant d'effectuer les opérations de réparation nécessaires, à distance. Il convient de noter que la formulation de ce problème, qui va également à l'encontre des habitudes de l'homme du métier, fait en soi partie de l'invention.

Un autre objectif de l'invention est de fournir une telle technique, qui permette d'effectuer des traitements de test, d'analyse et de réparation de façon très rapide, sans que le dispositif de radiocommunication soit immobilisé et inutilisable pendant de longues durées, supérieures à plusieurs heures voire plusieurs jours ou semaines.

L'invention a également pour objectif de fournir une telle technique, qui ne nécessite pas, de la part d'un utilisateur, une description complexe et complète de la situation dans laquelle le problème identifié se produit.

L'invention a également pour objectif de fournir une telle technique, qui ne suppose pas, dans les dispositifs de radiocommunication, de moyens techniques complexes, encombrants et coûteux.

Ces objectifs, ainsi que d'autres qui apparaîtront plus clairement par la suite, sont atteints à l'aide d'un procédé d'analyse du fonctionnement d'un terminal de radiocommunication selon un protocole de radiocommunication prédéterminé.

Selon l'invention, ledit terminal de radiocommunication transmet des données représentatives d'au moins une opération à analyser vers un dispositif d'analyse distant, via une liaison selon ledit protocole de radiocommunication prédéterminé.

Ainsi, l'analyse n'est pas effectuée en local, à l'aide d'appareils de test dédiés, qui doivent être connectés au terminal, mais de façon distante. Le terminal effectue lui-même, en interne, les opérations, et assure la transmission des informations à analyser vers un superviseur distant.

De façon avantageuse, le procédé de l'invention comprend une étape d'exécution d'une séquence d'au moins une opération, dans ledit terminal de radiocommunication, et stockage temporaire de données représentatives de la ou desdites opérations, suivie préférentiellement d'une étape de transmission différée desdites données représentatives de la ou desdites opérations, vers ledit dispositif d'analyse distant.

Selon un aspect avantageux de l'invention, lesdites étapes d'exécution et de transmission utilisant successivement le même protocole de radiocommunication.

L'approche de l'invention est donc de différer la transmission des données à analyser. Le terminal effectue lui-même toutes les opérations de test, puis transmet les données résultant de l'analyse (on peut également prévoir des transmissions périodiques, ou à des instants prédéterminés, de ces résultats, en cours de test).

Ainsi, il est possible d'utiliser le même lien (GSM, GPRS,...) pour la réalisation du test et sa supervision. En outre, il est possible d'utiliser, sur un site distant, des moyens puissants, sans qu'il soit nécessaire d'intervenir physiquement sur le terminal.

De façon préférentielle, le procédé de l'invention comprend une étape préalable de réception dans ledit terminal de radiocommunication d'un scénario d'analyse et/ou de paramètres d'analyse.

Lesdits paramètres peuvent notamment comprendre au moins un des éléments suivants: identification d'au moins un élément logiciel à analyser; identification d'au moins une donnée à transmettre; identification d'une séquence d'au moins une opération à effectuer; indication d'un niveau d'analyse.

Préférentiellement, ledit procédé comprend également une étape préalable de réception dans ledit terminal de radiocommunication de données de configuration de la transmission vers ledit dispositif d'analyse distant.

Lesdites données de configuration peuvent notamment comprendre au moins un desdits éléments suivants: un numéro de téléphone correspondant audit dispositif d'analyse 25 distant; des paramètres de configuration de la transmission de données vers ledit dispositif d'analyse distant.

Selon une caractéristique avantageuse de l'invention, le procédé met en oeuvre un cryptage pour la transmission de données vers et/ou depuis ledit 30 terminal de radiocommunication.

Notamment, il peut utiliser une clé de cryptage pour la transmission dudit scénario d'analyse et/ou desdits paramètres d'analyse.

L'invention peut également comprendre une étape subséquente de réception dans ledit terminal de radiocommunication de données de mise à jour, 5 en fonction de l'analyse desdites données.

De façon avantageuse, la ou lesdites étapes de réception utilisent également ledit protocole de radiocommunication.

Selon un mode de réalisation avantageux, ledit terminal de radiocommunication met en oeuvre un automate, piloté par un scénario transmis 10 par ledit dispositif d'analyse distant et/ou stocké dans ledit terminal de radiocommunication.

Préférentiellement, ledit scénario peut assurer la réalisation d'au moins une opération habituellement effectuée par un utilisateur dudit terminal de radiocommunication.

L'invention concerne également les terminaux de radiocommunication comprenant des moyens de mise en oeuvre du procédé d'analyse tel que décrit ci-dessus, ainsi que les dispositif d'analyse correspondant.

D'autres caractéristiques et avantages de l'invention apparaîtront plus clairement à la lecture de la description suivante d'un mode de réalisation 20 préférentiel de l'invention, donné à titre de simple exemple illustratif et non limitatif, et des dessins annexés parmi lesquels: - la figure 1 illustre, de façon schématique, le principe général de l'invention; la figure 2 est un schéma synoptique simplifié d'une mise en oeuvre du 25 procédé de l'invention.

L'invention repose donc sur une nouvelle approche de la détection et de l'analyse de problèmes ( debug en anglais) dans le domaine de la radiotéléphonie.

Selon l'invention, il n'y a en effet pas de supervision en direct, à l'aide 30 d'un appareil spécifique, sur ou par un accès indépendant, de type RS232C ou autre, mais une transmission en différé des informations utiles à l'analyse, préférentiellement à l'aide du protocole utilisé pour les communications elles-mêmes (par exemple GSM, GPRS, 3GPP, ...).

Ainsi, selon l'invention, il n'y a pas besoin de moyens spéciaux à proximité du terminal testé. C'est celui-ci qui fait lui-même les opérations, et qui stocke les données nécessaires à l'analyse. Il les transmet ensuite à un serveur distant, qui en effectuera en différé l'analyse, et le cas échéant retournera au terminal les correctifs nécessaires.

Il n'y a donc pas de complexité ajoutée au niveau du terminal (sauf à 10 l'exception de moyens logiciels), et il est en revanche possible de mettre en oeuvre des moyens d'analyse puissants, à distance.

Cette approche est notamment illustrée en figure 1.

Le dispositif de supervision 11 envoie au terminal 12 des données 13 de configuration de débogage.

Le terminal 12, qui peut être un radiotéléphone, ou des moyens de radiotéléphonie, tels qu'un module, implanté dans tout type de machine, reçoit et traite les données de débogage, qui comprennent notamment une séquence d'opérations à effectuer. Cette opération peut être produite à la suite de la réception d'un message 15 émis par le terminal 12.

Lorsque ces opérations ont été effectuées, le terminal 12 renvoie des données de résultats de débogage 14 vers le dispositif de supervision 11. Ce dernier effectue alors, en différé, les analyses correspondantes.

Cette approche permet donc d'effectuer des opérations de débogage à distance, et donc d'analyser les problèmes dans la situation et dans 25 l'environnement dans lesquels le problème apparaît effectivement.

Un aspect intéressant de l'invention est que l'on peut utiliser le même canal de communication (sans fil) pour: configurer le terminal pour les étapes de débogage; - effectuer ces étapes elles-mêmes; et renvoyer les résultats vers le superviseur.

Un exemple de mise en oeuvre est illustré en figure 2.

Le traitement commence généralement par l'identification 21 d'un problème dans le terminal. L'information correspondante d'identification d'un problème 22 est transmise vers le superviseur. Cette transmission peut être effectuée en automatique, en utilisant le réseau de radiocommunication, ou être demandée de façon indépendante, par exemple dans le cas d'une communication téléphonique vocale à un opérateur.

Dans d'autres cas, cette étape peut être supprimée, le superviseur pouvant décider de lui-même d'effectuer des tests, parce qu'il a lui-même identifié un 10 problème, ou simplement à titre de vérification périodique.

En fonction du problème à traiter, le superviseur établit et envoie (23) un scénario de test, ainsi que des paramètres de configuration correspondants. Ces paramètres peuvent notamment comprendre les éléments suivants: - informations pour joindre le superviseur et lui transmettre les données relevées: o piles de protocole http, WSP, propriétaire, ...) et adresse (par exemple, numéro de téléphone, URL, adresse IP, ...) ; o liens de transmission préférentiels (data, GPRS, ...) et stratégie d'utilisation (par exemple d'abord GPRS, et sinon SMS) ; o durée du test ou instants de transmission des données de débogage (la durée peut-être par exemple une heure, une journée ou une semaine) ; o paramètres de sécurité (pour éviter des utilisations mal intentionnées) : ^ codage autorisant le terminal à identifier le superviseur, de façon à obtenir des données contrôlées; ^ interface utilisateur permettant à l'utilisateur d'accepter ou de refuser une séquence de tests; o données de gestion de la trace de débogage: ^ taille maximale; 30 ^ buffer circulaire ou non; Les données 24 comprennent également un scénario de tests, décrivant l'ensemble des évènements et opérations que le terminal doit effectuer, pour 5 produire les données de débogage.

Le scénario est avantageusement un automate de test, implanté dans le terminal.

Il peut notamment définir: des évènements qui génèreront des opérations telles que: o des évènements qui lanceront le processus de test; o des indications de réseau (enregistrement, niveau, communications entrantes, SMS ou MMS entrants, ...) ; o expiration de temporisation; o indications relatives aux périphériques (accès USB, niveaux de batterie, charge de batterie, ...) ; o interaction liée à l'utilisateur (selon cet aspect, le terminal peut simuler des actions effectuées par l'utilisateur, telles qu'une frappe au clavier) ; des opérations, telles que: o des appels téléphoniques; o des envois de SMS ou MMS; o des accès WAP; o des enregistrements de réseaux; o des accès à la carte SIM; o des accès à l'annuaire du terminal; o des lancements d'applications de type applet Java; o Ces données 24 sont donc reçues et stockées (25) dans le terminal. Ce 30 dernier, au vu des données reçues, configure (26) le test à effectuer, puis l'exécute 20 25 et stocke les résultats de tests correspondants (27).

La description du scénario se présente avantageusement sous la forme d'un automate, c'est-à-dire une série d'évènements ou d'actions et de changements d'état. Un exemple d'automate pouvant être utilisé est décrit dans le document de brevet FR-0307992.

Plus généralement, le langage utilisé pour ces scénarios peut être un langage compilé ou interprété, propriétaire ou non.

Bien sûr, le terminal doit disposer de zones mémoire dédiées à ces opérations, d'une part pour stocker le scénario de test et les paramètres correspondants, et d'autre part pour stocker les résultats correspondants (traces de débogage) produits par l'exécution des tests.

Le terminal doit également disposer, dans son logiciel embarqué, des éléments permettant de mettre en oeuvre les différentes opérations liées au débogage.

Le terminal effectue donc (27) différentes opérations, simulant le fonctionnement habituel, en fonction des instructions du scénario reçu. Les données correspondantes, telles que définies dans les paramètres de tests, sont stockées en interne.

Lorsque le test est terminé (soit parce que la durée fixée est écoulée, soit 20 parce que le scénario défini est arrivé à la fin de celui-ci), l'ensemble des données de tests stockées sont transmises (28) vers le superviseur, qui va pouvoir les analyser (29) de façon différée.

En fonction de cette analyse, le superviseur pourra déterminer le problème, et envoyer les données de mise à jour correspondantes (30), soit de façon 25 autonome, soit à partir de données corrigées programmées par un opérateur.

Ces données de correction ou de mise à jour sont reçues (31) dans le terminal, qui les stocke aux endroits prévus à cet effet.

Ainsi, il est possible d'effectuer aisément et efficacement des opérations de débogage sur un terminal distant, sans qu'il soit nécessaire d'y connecter des 30 appareils de test. Les seuls moyens de communication utilisés sont des moyens de communication radiotéléphoniques classiques, disponibles dans le terminal (GSM, SMS, data, ...). Le terminal effectue lui-même la séquence de test, puis transmet ensuite les résultats en vue de leur analyse.

On donne ci-après un exemple de traitement selon l'invention.

Selon cet exemple, le protocole de communication utilisé entre le terminal et le superviseur est du type XML. Bien sûr, d'autres types de protocole sont utilisables.

Les données manquantes sont considérées par le récepteur comme les valeurs par défaut correspondantes.

En se référant à la figure 1, les opérations sont les suivantes: 15: le terminal 12 envoie un message au superviseur 11 pour requérir le lancement d'une séquence de test, par exemple parce qu'il a détecté un disfonctionnement local, par exemple sous la forme d'un appel téléphonique; le terminal attend un message en retour, de la part du superviseur. Il se place dans un mode spécifique dans lequel les données du superviseur seront traitées comme des données de débogage à distance; 13: le superviseur 11 envoie une séquence de test au terminal via une communication de données de type CSD, telle que: < !DOCTYPE REMOTE_DEBUG -//WIRELESS DEBUG 1.0 > <CONFIG PARAMETERS> <PROTOCOL_STACK>DEFAULT </PROTOCOL_STACK> <ADDRESS_SUPERVISOR> 0623456789</ADDRES S_SUPERV ISOR> <LINK>DATA CSD </LINK> <REMOTE_DATA_SCHEDULE>AFTER TEST COMPLETION <IREMOTE_DATA_SCHEDULE> <TRACE_LEVEL>SMS 1,TIMER 1 </TRACE_LEVEL> 30 11 </CONFIG_PARAMETERS> <TEST_SUITE> <STEP> <ACTION>SEND SMS, OWN NUMBER, TEXT, SMS TEST FOR REMOTE DEBUG </ACTION> <ISTEP> <STEP> <EVENT>WAIT SMS RECEPTION </EVENT> <EVENT>TIMEOUT=10S <IEVENT> </STEP> </TEST_SUITE> le terminal reçoit cette séquence, la stocke et effectue les opérations correspondantes: o envoyer un message de type SMS avec le texte SMS TEST FOR REMOTE DEBUG à son propre numéro; o attendre la réception de ce message ou l'expiration d'un délai de 10 secondes; - chacune de ces opérations génère des informations de débogage dans les couches: o SMS ( Short Message Service , ou message court) niveau 1; o TIMER (temporisation) niveau 1, qui sont stockées dans le terminal; - 14: à la fin du test, les informations de débogage collectées sont transmises vers le superviseur, en utilisant une communication CSD DATA au numéro de téléphone 0623456789 , par exemple sous la forme: < !DOCTYPE REMOTE DEBUG -//WIRELESS DEBUG 1.0 > 12 2861945 <TEST_SUITE_RESULT> <STEP> <TRACE _LEVEL>SMS 1 </TRACE_LEVEL> <DATA> SMS send to 0611112222 (le numéro de téléphone) text = SMS TEST FOR REMOTE DEBUG </DATA> </STEP> <STEP> <TRACE_LEVEL>TIMER 1 </TRACE_LEVEL> <DATA> 10 seconds timer expiry </DATA> </STEP> </TEST_SUITE_RESULT> le superviseur analyse les résultats du test et détecte que: o un message SMS a été envoyé par le terminal vers lui-même; o mais que celui-ci n'a pas été reçu dans le délai fixé de 10 20 secondes; o et suspecte donc un problème de réception de SMS, dû au fait que le nombre maximal de SMS stockables dans le terminal est atteint; le superviseur informe le terminal (ou son utilisateur) qu'il doit effacer des SMS pour libérer de la place mémoire.

Bien sûr, il ne s'agit là que d'un exemple simplifié, illustrant l'approche de l'invention. Des scénarios plus complexes, adaptés à chaque situation, sont possibles. 10

13 2861945

Claims (15)

REVENDICATIONS

1. Procédé d'analyse du fonctionnement d'un terminal de radiocommunication selon un protocole de radiocommunication prédéterminé, caractérisé en ce que ledit terminal de radiocommunication transmet des données représentatives d'au moins une opération à analyser vers un dispositif d'analyse distant, via une liaison selon ledit protocole de radiocommunication prédéterminé.

2. Procédé d'analyse selon la revendication 1, caractérisé en ce qu'il comprend une étape d'exécution d'une séquence d'au moins une opération, dans ledit terminal de radiocommunication, et stockage temporaire de données représentatives de la ou desdites opérations, et une étape de transmission différée desdites données représentatives de la ou desdites opérations, vers ledit dispositif d'analyse distant.

3. Procédé d'analyse selon la revendication 2, caractérisé en ce que lesdites étapes d'exécution et de transmission utilisant successivement le même protocole de radiocommunication.

4. Procédé d'analyse selon l'une quelconque des revendications 1 à 3, caractérisé en ce qu'il comprend une étape préalable de réception dans ledit terminal de radiocommunication d'un scénario d'analyse et/ou de paramètres d'analyse.

5. Procédé d'analyse selon la revendication 4, caractérisé en ce que lesdits paramètres comprennent au moins un des éléments suivants: identification d'au moins un élément logiciel à analyser; identification d'au moins une donnée à transmettre; identification d'une séquence d'au moins une opération à effectuer; indication d'un niveau d'analyse.

6. Procédé d'analyse selon l'une quelconque des revendications 1 à 5, caractérisé en ce qu'il comprend une étape préalable de réception dans ledit terminal de radiocommunication de données de configuration de la transmission vers ledit dispositif d'analyse distant.

7. Procédé d'analyse selon la revendication 6, caractérisé en ce que lesdites données de configuration comprennent au moins un desdits éléments suivants: un numéro de téléphone correspondant audit dispositif d'analyse distant; des paramètres de configuration de la transmission de données vers ledit dispositif d'analyse distant.

8. Procédé d'analyse selon l'une quelconque des revendications 1 à 7, caractérisé en ce qu'il met en oeuvre un cryptage pour la transmission de données vers et/ou depuis ledit terminal de radiocommunication.

9. Procédé d'analyse selon les revendications 4 et 8, caractérisé en ce qu'il utilise une clé de cryptage pour la transmission dudit scénario d'analyse et/ou desdits paramètres d'analyse.

10.. Procédé d'analyse selon l'une quelconque des revendications 3 à 6, caractérisé en ce qu'il comprend une étape subséquente de réception dans ledit terminal de radiocommunication de données de mise à jour, en fonction de l'analyse desdites données.

11. Procédé d'analyse selon l'une quelconque des revendications 4 à 10, caractérisé en ce que la ou lesdites étapes de réception utilisent également ledit protocole de radiocommunication.

12. Procédé d'analyse selon l'une quelconque des revendications 1 à 11, caractérisé en ce que ledit terminal de radiocommunication met en oeuvre un automate, piloté par un scénario transmis par ledit dispositif d'analyse distant et/ou stocké dans ledit terminal de radiocommunication.

13. Procédé d'analyse selon la revendication 12, caractérisé en ce que ledit scénario assure la réalisation d'au moins une opération habituellement effectuée par un utilisateur dudit terminal de radiocommunication.

14. Terminal de radiocommunication caractérisé en ce qu'il comprend des moyens de mise en oeuvre du procédé d'analyse selon l'une quelconque des revendications 1 à 13.

15. Dispositif d'analyse distant caractérisé en ce qu'il comprend des moyens 2861945 de mise en oeuvre du procédé d'analyse selon l'une quelconque des revendications 1à13.