Système Expert pour Smartphones

(1)

INSA Rennes – Département INFORMATIQUE

Système Expert pour Smartphones

Rapport de Spécification

Romain Boillon;Olivier Corridor;Quentin Decré;Vincent Le Biannic;Germain Lemasson;Nicolas Renaud;Fanny Tollec

2010-2011

Projet sous la direction de Laurence Rozé

(2)

1 | P a g e

T ABLE DES MATIÈRES

1. INTRODUCTION... 3

2. PRÉSENTATION GÉNÉRALE ... 3

2.1. CONTEXTE ET OBJECTIFS ... 3

2.2. RAPPEL DU PROJET DE L’ANNÉE PRÉCÉDENTE ... 4

2.3. EVOLUTION DU PROJET À CETTE ANNÉE ... 4

2.3.1. Type de Smartphone ... 5

2.3.2. Réécriture du système expert ... 5

2.3.3. Nouveau système de Monitoring ... 6

2.3.4. Création d’un module de surveillance des actions de l’utilisateur... 6

2.3.5. Nouvelle machine learning pour l’apprentissage ... 6

2.3.6. Interaction avec l’utilisateur ... 6

2.4. PLATEFORMES DE DÉVELOPPEMENT ... 7

2.4.1. Android ... 7

2.4.2. iPhone ... 7

2.4.3. Langages ... 7

2.4.4. IDE ... 8

3. SPÉCIFICATION ... 9

3.1. FONCTIONNEMENT GÉNÉRAL ... 9

3.1.1. Evolution ... 9

3.1.2. Exemple de fonctionnement ... 10

3.1.3. Format XML des rapports ... 11

3.1.4. Format XML des règles ... 12

3.2. PARTIE SERVEUR ... 14

3.2.1. Apprentissage ... 14

3.2.2. Base de connaissance ... 17

3.2.3. Interface administrateur ... 18

3.3. PARTIE EMBARQUÉE (MOBILE) ... 19

3.3.1. Introduction ... 20

3.3.2. Système de reporting ... 20

3.3.3. Suivi de l’utilisateur ... 22

3.3.4. Système expert... 22

(3)

2 | P a g e 4. CONCLUSION ... 25 5. BIBLIOGRAPHIE ... 27

(4)

3 | P a g e

1. Introduction

Manage Yourself est un projet de diagnostic et de surveillance de plateformes embarquées, inscrit dans une collaboration entre Telelogos et DREAM. Notre but est cette année de créer, pour iPhone et mobiles Android, une application capable de comprendre, puis d’anticiper et prévenir les pannes possibles de ces mobiles.

Sur la base de nos recherches de pré-études, nous avons pu définir les objectifs à atteindre, à savoir créer des rapports d'erreur et de bon fonctionnement du système, améliorer l'apprentissage du projet de l'an passé et rendre notre application exportable sur divers systèmes existants. Les outils à notre disposition seront constitués de logiciels de développement, de simulateurs, de machines mobiles et enfin de serveurs.

Ce rapport présentera dans un premier temps quels sont les objectifs de notre projet : de quelle manière nous avons décidé de reprendre le projet de l’année précédente, quels sont nos objectifs précis de modification, d’adaptation sur Android et iOS, et d’amélioration de ce projet.

Puis nous définirons quelles seront les nouvelles fonctionnalités de ce produit, répondant aux attentes de Télélogos. Notre cahier des charges, ainsi que l’étude de faisabilité pré requise pour ce projet, nous laissait une marge de décision pour choisir différentes fonctionnalités les plus pertinentes. Ces choix maintenant décidés vous seront présentés ici.

Nous spécifierons également le fonctionnement de l’ensemble des composants du projet.

2. Présentation Générale

2.1. Contexte et objectifs

ManageYourself est un projet de diagnostic et surveillance de plateformes embarquées, il s'inscrit dans le cadre d'une collaboration entre Telelogos et DREAM. Telelogos est une entreprise éditant des logiciels professionnels qui automatisent, administrent et optimisent les processus d’échanges entre système informatique central et ceux des utilisateurs distants.

DREAM est une équipe de recherche de l'IRISA spécialisée dans l'aide à la surveillance et au diagnostic de systèmes évoluant dans le temps. Le besoin de développer une telle application émane de Telelogos, qui cherche à exploiter les possibilités dans le domaine du MBM (Mobile Device Management).

(5)

4 | P a g e Le but de notre projet cette année est de développer une plateforme de surveillance pour les Smartphones iPhone et Android, dont la part de marché ne cesse d'augmenter. L'application sera directement embarquée sur les Smartphones concernés et tournera en tâche de fond. Le but est de récupérer les éventuelles erreurs de fonctionnement et de générer les rapports correspondant à ces erreurs potentielles. Ces rapports donnent ensuite un diagnostic de l'erreur rencontrée. D'autre part, l'application doit également générer des rapports de bon fonctionnement de l'appareil à intervalles réguliers. Ces rapports permettront par la suite d'implémenter une liste de règles à appliquer donnant la possibilité d'anticiper les erreurs éventuelles et de réagir en conséquence. Ils contiendront les spécifications des Smartphones aux instants durant lesquels ils ont été générer, par exemple la mémoire occupée ou libre, ou encore le niveau de la batterie.

2.2. Rappel du projet de l’année précédente

Le projet ManageYourself entreprit l’année dernière était un projet de surveillance de plates-formes embarquées dont le but était de développer une plateforme de surveillance sur des appareils de type Smartphone ou PDA, fonctionnant sous Windows mobile. L’application devait être embarquée sur l’appareil et constamment renseignée sur l’état du système afin de détecter et de remédier { n’importe quel problème du PDA.

Cette application contient un système expert. C’est la partie du logiciel qui gère l’aspect décisionnel. A partir d’une base de faits et de règles, il doit être capable de déduire des faits et d’exécuter des actions. Composé d'une base de fait, d'une base de règles et d'un moteur d'inférence, le système expert se devait d’être léger pour tourner en tâche de fond sur l'appareil.

Le projet était découpé en deux parties : l'une d'entre elles était l'application même sur le Smartphone. Elle devait suivre les règles acquises pour éviter les plantages potentiels, et générer des rapports d'erreur lors d'un plantage, et de bon fonctionnement si plantage il n'y avait pas.

L'autre était la partie serveur, s'occupant de l'apprentissage des règles et de les envoyer au Smartphone.

La communication entre ces deux parties était gérée par MediaContact, logiciel composé d'une partie serveur, une console d'administration et du logiciel client à déployer sur le mobile.

Cette application était chargée de récupérer les rapports et de gérer l'installation modifiée par les apprentissages.

2.3. Evolution du projet à cette année

(6)

5 | P a g e Le projet de cette année est découpé de la même manière que celui de l’année dernière, { savoir :

 D’une application mobile tournant en tâche de fond sur le Smartphone

 D’une application serveur

Mais le système expert de l'an dernier avait quelques points faibles. On peut entre autres relever le fait qu'il n'y avait pas de mise à jour des plus anciens attributs de la base de faits, tandis que les applications sont régulièrement mises à jour. Bien entendu, l'application ne fonctionnait que sur Windows mobile, donc très restrictif concernant sa portée sur les systèmes mobiles. C’est pourquoi cette année plusieurs modifications majeures lui seront apportées :

 Développement de l’application sur de nouveaux types de Smartphones

 Réécriture du système expert

 Nouveau système de Monitoring

 Création d’un module de surveillance des actions de l’utilisateur

 Nouvelles machine learning pour l’apprentissage

 Mise en place d’interactions avec l’utilisateur

2.3.1. Type de Smartphone

L’application mobile de l’année dernière a été conçue pour les Smartphones et PDA tournant sous Windows Mobile. Cette année elle sera implémentée sur les Smartphones équipés de l’OS Android, ainsi que sur les iPhones.

Ceci implique par exemple que le code constituant l’application mobile soit générique aux deux différents systèmes d’exploitation. Il s’agira donc bien d’une seule application, mais qui sera compilée en deux langages différents, afin qu’elle soit utilisable sur iPhone et Androïd.

2.3.2. Réécriture du système expert

Le système expert de cette année reprendra globalement la forme de celui de l’année précédente, mais il sera adapté aux nouvelles plateformes.

(7)

6 | P a g e

2.3.3. Nouveau système de Monitoring

Cette année les informations nécessaires au système expert seront récupérées de plusieurs manières :

 En lisant les informations offertes par les différents OS (état de la batterie, nom et version de l’OS, état de la mémoire…), similairement au projet précédent.

 En récupérant les fichiers de logs des deux OS, comprenant des rapports sur l’état du système au cours du temps (création de rapports d’erreur et de bon fonctionnement).

Le système expert bénéficiera alors d’un ensemble de données complet { analyser, ce qui permettra de traiter un panel de problèmes plus larges sur les différents OS.

2.3.4. Création d’un module de surveillance des actions de l’utilisateur

Nous étudions par ailleurs la possibilité de capter l’ensemble des actions de l’utilisateur sur son Smartphone, afin de les intégrer au diagnostic du système expert. En effet suite à des discussions avec des professionnels, il s’avère qu’assez souvent les plantages des Smartphones ne sont pas liés { des problèmes matériels ou logiciels mais { des problèmes d’utilisation. Nous chercherons donc { générer un fichier de log contenant l’ensemble de ces actions, en y joignant des informations supplémentaires sur l’environnement (coordonnées GPS, qualité du signal…).

Néanmoins cette partie est clairement une voix exploratoire, c’est pourquoi elle constitue un module à part.

2.3.5. Nouvelle machine learning pour l’apprentissage

Du fait d’une base de données plus importante { analyser, la partie apprentissage sera elle aussi revue, afin d’intégrer les rapports de bon et mauvais fonctionnement. De plus cette année nous chercherons { optimiser l’entretien de la base de connaissance, en supprimant par exemple les anciennes règles devenues inutiles.

2.3.6. Interaction avec l’utilisateur

Le système expert devra par ailleurs envoyer { l’utilisateur des notifications avant de réaliser chaque action sur son Smartphone. Il aura ainsi la possibilité de les accepter ou de les refuser. Notre application mobile sera donc plus transparente et adaptée aux besoins de l’utilisateur.

Ces différentes modifications seront vues plus en détail dans la partie Spécification.

(8)

7 | P a g e

2.4. Plateformes de développement

2.4.1. Android

Le projet devra fonctionner sous le système d'exploitation Android.

Ce dernier, open source, est basé sur un noyau Linux et est principalement destiné aux plateformes mobiles (smartphones, PDA, ...).

Pour exécuter des applications, le système se base sur un principe de machines virtuelles, appelées machines virtuelles Dalvik, capables de gérer des programmes développés en Java.

2.4.2. iPhone

Le projet devrai aussi fonctionner sur un iPhone c'est-à-dire sous le système d’exploitation iOS.

L’iOS est le système d’exploitation des iDevices (iPhone, iPad, iPod touch) développé par Apple. Nous en sommes actuellement { la version 4. C’est un système désormais multitâche ce qui nous intéresse dans le cadre de ce projet, de ce fait nous ne nous intéresserons pas aux précédentes versions.

2.4.3. Langages

Comme dit précédemment, les applications à destination d'un appareil sous Android, doivent être développées en Java. Il faut cependant noter qu'il est possible d'utiliser du code en langage C en le compilant en code natif ARM intégrable dans le code à l'aide du kit de développement dédié (Native Development Kit). Toutefois, cette solution reste complexe à mettre en place, la librairie C ne respectant pas forcément les normes. Cela est donc en général seulement utilisé par des librairies ou dans des parties de code nécessitant une forte optimisation des performances.

Le développement d’application iPhone ne peut se faire qu’en Objective-C, c’est le langage utilisé par le SDK de l’iOS 4. C’est un langage qui ne ressemble { aucun autre syntaxiquement. Afin de développer une application pour iPhone, nous allons devoir utiliser l’API (Application Programming Interface) Cocoa qui est l’infrastructure de base des applications et qui permet notamment de créer et d’interagir avec les interfaces graphiques utilisateur.

(9)

8 | P a g e

2.4.4. IDE

Pour Android, l'IDE utilisé pour le développement sera le logiciel libre Eclipse.

Environnement de développement gérant de nombreux langages à l'aide d'un système de plugins, il permet la création d'applications en Java, langage de base des programmes Android.

XCode est l’outil développement officiel d’Apple pour réaliser des applications pour le système d’exploitation de l’iPhone (iOS 4). Il permet de développer facilement sous Mac OS X des applications avec interface graphique pour iPhone.

Pour développer une application multitâche sous iOS 4 nous avons dû installer la dernière version de Mac OS X (la 10.6), puis XCode (la 3.2.4) qui contient le SDK de l’iOS 4 pour pouvoir développer des applications multitâches et les tester sur émulateur ou directement dans un iPhone.

(10)

9 | P a g e

3. Spécification

3.1. Fonctionnement général

3.1.1. Evolution

Nous avons choisi de faire évoluer le fonctionnement général du système pour le rendre plus générique et l’optimiser.

Il faut également noter que cette recherche de généricité et d’optimisation se retrouve également dans la partie embarquée et la partie serveur. Ces évolutions sont détaillées dans leurs parties respectives. Nous présenterons dans cette première partie les évolutions des interactions entre le serveur et les mobiles.

L’évolution passe par un changement des données échangées.

Partie serveur

Partie embarquée

Interface de communication

Rapports binaires Nouveau système expert

Remplaçant l’ancien

FIGURE 1 - FONCTIONNEMENT GÉNÉRAL DU PROJET PRÉCÉDENT

Auparavant, le système expert envoyait des rapports binaires qu’il fallait décompresser puis convertir au format adéquat. Cela présente de nombreux inconvénients, et n’est pas indispensable pour un projet d’étude, et non destiné { être mit en production. Le format n’est pas lisible par l’homme, et nécessite un décodage. Ce n’est donc pas pratique { manipuler.

Puis, sur la base de ces rapports intervient alors l’apprentissage puis la définition des actions par l’administrateur. C’était alors un nouveau système expert qui était compilé sur la base de ces règles, puis qui était réinstallé sur le mobile. Là encore, ce système présente des problèmes. Tout d’abord, le système n’est pas générique. En effet, le résultat n’est compatible

(11)

10 | P a g e qu’avec un seul type de smartphone. De plus, dans la mesure où une étape de compilation est nécessaire, on limite les systèmes possibles pour le serveur. Par exemple, le compilateur C# n’est pas installé sur les systèmes Mac.

Aujourd’hui, nous souhaitons avoir un serveur d’une part, chargé de l’apprentissage et la définition des règles, sur la base de rapports communiqués par le mobile, et la partie embarquée qui récupère un fichier contenant les règles et se charge d’appliquer dynamiquement ces règles, et envoyer des rapports au serveur.

Partie serveur

Partie embarquée

Interface de communication

Rapports au format XML Règles au format XML

FIGURE 2 - FONCTIONNEMENT GÉNÉRAL PRÉVU

Pour rendre cette communication la plus générique possible, nous avons choisi le format XML. Ainsi, nous avons établi deux formats de fichiers XML :

 Format des rapports

 Format des règles

3.1.2. Exemple de fonctionnement

Mais le mieux, pour commencer est de saisir correctement le mécanisme dans son ensemble. Pour l’illustrer, nous allons suivre un exemple complet.

(12)

11 | P a g e

Système expert sur le smartphone

Génération du rapport XML suivant

</rapport>

Récupération du rapport par le

serveur

Apprentissage sur la base des anciens

rapports et du nouveau

Définition par l’administrateur de

l’action « tuer B »

Génération du fichier XML des

règles

Envoi du fichier XML sur le mobile Lecture et début de

l’inférence des faits dans le but de déclencher les

actions adéquates Détection de B

lancé Message pour proposer le kill de B

Si oui Kill de B

Supposons ici que ce nouveau rapport entraine la déduction que l’applicationB est responsable du plantage

FIGURE 3 - EXEMPLE DÉMONTRANT LE MÉCANISME

3.1.3. Format XML des rapports

On distingue deux types de rapports :

 Les rapports de bon fonctionnement

 Les rapports de crash

Ces deux types de rapports indiquent la date du rapport, ainsi que les valeurs de nombreux attributs comme la mémoire, les applications lancées… Naturellement, comme indiqué sur la figure ci-dessous, le fichier XML respecte cette structure des rapports.

(13)

12 | P a g e Report

Date FreeMemory TotalMemory ApplicationA BatteryLevel ... Crash

Un rapport Un timestamp (nombre de

secondes depuis le 1er janvier 1970 à minuit UTC)

Il peut y avoir un fils par type d’attributs dont on souhaite

avoir la valeur dans le rapport.

Facultatif: à mettre si un crash a été

détecté

FIGURE 4 - STRUCTURE DU DOCUMENT XML : RAPPORT

Il est { noter que nous avons choisi d’utiliser un timestamp pour la date afin d’éviter tout problème de référentiel, et de limiter le nombre d’attributs composant la date { un seul.

Exemple de fichier rapport :

...

</rapport>

3.1.4. Format XML des règles

Le schéma ci-dessous indique la structure du fichier XML, et l’organisation des balises.

L’objectif final est d’arriver { retrouver une similarité entre le fichier XML et la structure des classes que nous développerons pour simplifier la lecture du fichier XML, et donc des règles.

(14)

13 | P a g e

Rules

Rule Rule Rule

Conditions

Condition Condition Condition

Actions

Action Action Action

Attribut Integer|Strin g|...

Ensemble de règles.

Les conditions (ET) doivent être vérifiées pour que les actions soient déclenchées

Plus d’une action peut être déclenchée Une règles est composée

de conditions et d’actions

Il existe différents types de condition (appartenance,

égalité,…).

Toutes les conditions portent sur un attribut (Mémoire

libre, processus fonctionnant…).

En fonction du type, les fils suivant l’attribut peuvent varier en nombre et

type.

Il y a deux types d’action : la génération d’un fait (exemple : si MémoireLibre < 10, on peut générer

StatutMémoire = saturée) L’execution d’une action comme un kill, libérer de la mémoire, afficher une alerte...

FIGURE 5 - STRUCTURE DU DOCUMENT XML : REGLES

Notre fichier de règles est donc tout simplement un ensemble de règles. Une règle est elle-même un ensemble de conditions devant être vérifiées, qui entraîne l’exécution d’une ou plusieurs actions. Chaque condition comporte un « type » (appartient, égal, inférieur,…), un attribut (mémoire libre, nom de fonctionnement), et une valeur ou ensemble. On retrouve la structure opérande gauche, opérateur, opérande droite. Ce système permet de modéliser toutes formes de conditions. Voici quelques exemples possibles :

 memoireTotale = 250

 applicationA = lancee

 mémoireLibre < 120

 …

On distingue deux types d’actions :

 Les actions générant un fait pour alimenter l’inférence (exemple : si MémoireLibre <

10, on peut générer StatutMémoire = saturée).

(15)

14 | P a g e

 Les actions agissant sur le système. Il est évident que les différentes actions spécifiées dans les règles doivent être prévues dans le système expert.

On obtient finalement un fichier de règles similaire { l’exemple ci-dessous.

Exemple de fichier de règles :

<rules>

</condition>

</condition>

</conditions>

</actions>

</rule>

</rules>

3.2. Partie serveur

3.2.1. Apprentissage

L’apprentissage, tout comme l’année dernière, se fera grâce { la librairie weka qui contient de nombreux algorithmes. Nous utiliserons notamment ceux qui portent sur la classification. Plusieurs aspects sont à prendre en compte : comment gérer les rapports de bon et mauvais fonctionnement, l’évolution dans le temps de ces rapports, puis celle des règles apprise par le système expert et pour finir la dynamique des attributs.

3.2.1.1. Rapport de bon et mauvais fonctionnement

La librairie weka prend en entrée des fichiers de type arff qui ont le format suivant.

(16)

15 | P a g e Il y a séparation entre la définition des attributs et les données. L’année dernière les rapports de bon et mauvais fonctionnement avaient le même format. Il était donc aisé de trouver les attributs à utiliser.

Cette année, la pré-étude a montré que les rapports de mauvais fonctionnement contiennent uniquement les informations en relation avec le crash. Les informations manquantes se trouvent dans les rapports de bon fonctionnement qui ont un format différent.

Nous allons explorer deux façons de faire.

Une première solution est de compléter les attributs manquants avec les rapports de bon fonctionnement remontés juste avant et juste après en suivant certaine règle.

Avant Bug Après

AppliA=lancée lancée AppliA=lancée

AppliA=lancée ? AppliA=nonlancée

AppliA=nonlancée nonlancée ? AppliA=nonlancée

Le point d’interrogation (?) permet de ne pas choisir la valeur. Le 3eme cas est plus compliqué à gérer. Est-ce correct de penser que l’application est non lancée ? Imaginons qu’elle soit la cause du bug, cela induirait en erreur l’apprentissage.

Une deuxième solution possible serait de gérer des tuples d’attribut.

( , … , , , … , , , … , )

Ou serait les attributs des rapports de bon fonctionnement et les les attributs du rapport de bug. Cette deuxième solution semble plus correct mais implique de doubler voir tripler le nombre d’attribut.

3.2.1.2. Evolution dans le temps des rapports remontés

Lors de la première utilisation du système expert les rapports générés vont être aléatoires mais dès que celui-ci aura une base de connaissance non vide ce ne sera plus le cas. En effet grâce au système expert un certain nombre de rapports d’erreurs ne pourront plus être générés vu que leurs causes seront évitées. Le simulateur de l’année dernière doit donc évoluer dans ce sens. Une première solution serait de filtrer les exemples créés en retirant ceux qui correspondent à des règles déjà présentes dans la base de connaissance. Cela implique de créer un filtre pour chaque règle, ce qui est bien trop contraignant. Une seconde solution serait de faire un simulateur incluant les mobiles et le système expert. Ainsi les rapports générés seraient systématiquement en adéquation avec les règles du système expert.

(17)

16 | P a g e

3.2.1.3. Gestion des règles

Premièrement leur création. L’année dernière { l’arrivée d’un nouveau paquet de rapport, tous les paquets étaient concaténés et l’apprentissage était refait sur ces données. Cette année notre but est d’automatiser cette procédure. L’apprentissage se fera sous cette forme.

Ensuite les règles inutiles ou devenues obsolètes dans le sens où elles ne sont plus utilisées. Effectivement des règles peuvent devenir inutiles, par exemple { cause d’une mise à jour ou de la suppression d’une application. Donc en remontant les rapports, il faut aussi remonter des informations sur leurs utilisations. Un bilan des règles utilisées est donc créé à chaque lancement du système expert. La spécification de ces bilans sera vue dans la partie 3.3 Partie Embarquée.

Un cas plus délicat à prendre en compte est l’exécution de règles inutiles ou erronées mais qui sont quand même exécutées. Dès qu’une règle sera appliquée, l’utilisateur devra accepter ou non les actions à effectuer. Trois choix lui seront possibles. Appliquer, Ne pas appliquer, Inefficace. On peut ensuite envisager de traiter ces résultats automatiquement ou manuellement pour plus de sécurité.

3.2.1.4. La dynamique des attributs

Nous venons de voir que les règles évoluent dans le temps. C’est aussi le cas pour les attributs et ceci principalement pour les mêmes raisons. Certains attributs comme le niveau de batterie, la charge de la mémoire, le type de l’OS utilisé, seront toujours présents dans les rapports. Cependant le nombre d’attributs liés aux applications est amené { varier. Il faudra détecter à quel moment un attribut devient superflu. Par exemple si un attribut n’apparait plus

Apprentissage

@relation simulateur

@attribute memoire NUMERIC

@attribute applicationA {lancee,nonLancee}

@attribute applicationB {lancee,nonLancee}

@attribute applicationC {lancee,nonLancee}

...

Règles paquet 1

@relation simulateur

@attribute memoire NUMERIC

@attribute applicationA {lancee,nonLancee}

@attribute applicationB {lancee,nonLancee}

@attribute applicationC {lancee,nonLancee}

...

Apprentissage Règles paquet 2

FIGURE 6 - APPRENTISSAGE

(18)

17 | P a g e dans aucun rapport et aucune règle utilisée il y a de grande chance de pouvoir le supprimer sans risque.

En plus de cet aspect temporel des attributs il faut aussi voir leur aspect matériel.

L’année dernière le système expert était utilisé uniquement sur la plateforme Windows mobile.

Les attributs étaient donc uniques pour tous les types de mobile. Or cette année le système expert sera utilisé pour deux systèmes d’exploitation différents (IOS et Android). Certains attributs seront probablement spécifiques à l’un d’entre eux. Ils ne devront donc pas être pris en compte pour l’apprentissage des règles du second.

Arriver à gérer tous cet ensemble de contraintes liées aux attributs sera certainement une part importante du travail à effectuer dans la partie apprentissage.

3.2.2. Base de connaissance

La base de connaissance contient les données utilisées par le système expert pour prévenir les problèmes déjà survenus sur le Smartphone. Dans notre cas elle sera constituées d’un ensemble de règles, dites règles de productions. Les règles sont générées par l’apprentissage puis converties en XML afin de pouvoir être traitées par l’interface administrateur.

Nous avons vu précédemment un exemple de fichier de règle en XML :

<rules>

<rule>

</condition>

</condition>

</conditions>

</actions>

</rule>

</rules>

Les règles sont composées d’une ou plusieurs conditions ainsi que d’une ou plusieurs actions. Elles sont donc de la forme SI condition(s) ALORS action(s). L’opérateur logique utilisé entre les différentes conditions est donc la conjonction. Ce n’est pas une restriction, car si on veut utiliser la disjonction « Si condition1 ou condition2 ALORS actions(s) » il suffit alors de créer deux règles distinctes « Si condition1 ALORS action(s) », « Si condition2 ALORS action(s) ».

Les actions effectuées vont alors empêcher le bug associé à la règle de survenir. Ainsi on ne cherche pas spécialement { résoudre le bug mais bien { l’éviter.

(19)

18 | P a g e Il existe plusieurs types de conditions. Sur cet exemple le type ‘’between’’ associé au sujet FreeMemory et aux deux valeurs 0 et 100 signifiera « Si l’espace libre en mémoire est compris entre 0 et 100 ». En pratique, le type « between » sera traité en deux temps, on utilisera les opérateurs inférieur (<) et supérieur (>). Notre condition devient alors : « Si l’espace libre en mémoire est supérieur { 0 et inférieur { 100 alors… ».

Nous devrons donc définir un nombre suffisant de types pour quantifier l’ensemble des conditions à traiter. Par ailleurs ces conditions sont liées aux différentes informations récupérées dans les rapports.

Les différentes actions correspondent aux interventions possibles réalisables selon le système d’exploitation du Smartphone.

La base de connaissances sera gérée par l’interface administrateur { partir des règles générées par l’apprentissage. Elle sera séparée en plusieurs sous-ensembles qui correspondront aux différents types de mobiles utilisés. Cet ensemble de règles sera stockée sur le serveur sous forme de fichiers XML puis transmises { chaque appareil mobile, selon son type. Enfin l’interface administrateur permettra d’éditer la base de connaissances.

3.2.3. Interface administrateur

Une interface administrateur devra être présente sur le serveur, elle permettra de visualiser facilement toutes les règles présentes. Elle permettra également de supprimer des règles ou d’en saisir de nouvelles.

(20)

19 | P a g e

FIGURE 7 INTERFACE ADMINISTRATEUR

1) Ensemble des règles déjà présentes dans le système expert.

2) Ensembles des règles apprises, en cliquant sur « étiqueter » on rajoute la règle aux conditions (3).

3) Ensemble des conditions qui constitueront la nouvelle règle. On peut en ajouter et en supprimer.

4) Action appliquée si les conditions sont remplies.

En validant les conditions (3) et les actions (4) la nouvelle règle est ajoutée à la base de connaissance.

Il faut, par ailleurs, que lorsqu’une action est choisie, celle-ci soit implémentée (et donc possible à exécuter) sur la partie embarquée.

3.3. Partie Embarquée (mobile)

Notre objectif cette année est de pouvoir récupérer puis résoudre les différentes pannes que peuvent subir un iPhone ou un téléphone sous Android. Nous allons créer un ensemble de systèmes, embarqués sur le mobile en question, capables de diagnostiquer et d’anticiper les pannes de celui-ci sans l’aide d’un tiers ordinateur (mais épaulé par un serveur pour l’apprentissage).

(21)

20 | P a g e

3.3.1. Introduction

On distingue deux choses sur le mobile :

 Le système de reporting, qui génère des rapports

 Le système de suivi utilisateur qui enregistre les actions de l’utilisateur

 Le système expert qui { partir des règles et des rapports fait l’inférence pour exécuter les actions.

3.3.2. Système de reporting

Des méthodes différentes ont été choisies pour la génération des rapports, en fonction du système visé. Nous allons en premier lieu introduire la méthode choisie pour Android.

La création des rapports sous Android se fera périodiquement (lors du bon fonctionnement de l’appareil), et lors de la détection d'un bug.

La détection des bugs sera effectuée { l’aide d’un utilitaire intégré { Android, du nom de « logcat ». Ce dernier permet de récupérer en temps réel les journaux (logs) créés par le système et les applications qu’il exécute. Ainsi, en traitant les lignes de log générées, il est possible de détecter les divers évènements en provenance de l’appareil (ouverture d’une application, fermeture d’une application, plantage, …). L’appel { des applications externes étant autorisé depuis le code Java d’un programme, on peut donc exécuter logcat et récupérer sa sortie dans un buffer qui sera alors traité.

En revanche, dû au système d’exceptions de la machine virtuelle Dalvik, certains développeurs choisissent de cacher ce genre de problème (par exemple en relançant une application lors d’un bug sans émettre de ligne de log standard), ce qui pourra peut-être poser problème et parfois fausser la détection.

La génération des rapports se fera { l’aide d’une application dédiée. Elle sera chargée de récupérer les diverses informations système, et de les rassembler dans un fichier XML.

Sous iPhone les rapports de bon fonctionnement et ceux de bug sont générés de manières différentes. En effet les rapports de bon fonctionnement vont être générés par notre système expert directement en XML dans le format spécifié précédemment.

Pour ce qui est des rapports de bug, ils vont être générés à partir des crashs log fournis par le téléphone. En effet lorsqu’une application plante, ou que le téléphone plante { cause d’une saturation mémoire ou d’une batterie déchargée, le téléphone génère automatiquement un crash

(22)

21 | P a g e log. Pour le cas d’un crash log généré lorsqu’une application a crashé nous pouvons récupérer dans cet ordre : le modèle du téléphone, le processus qui a planté, la version du processus, la date et l’heure du crash, la version de l’OS.

Lorsque la mémoire est saturée, le crash log généré nous donne : le modèle du téléphone, la version de l’OS, l’heure et la date du crash, le nombre de pages mémoires libres, le nombre de pages mémoires utilisés, le nombre de pages mémoires pouvant être vidés, le processus utilisant le plus de mémoire et la liste des processus lancés.

Pour le cas de la batterie faible, nous pouvons récupérer la date et l’heure du crash, la version de l’OS, le temps de veille, le temps d’utilisation, la capacité et le voltage de la batterie.

Ces crashs log ne sont accessibles que lors d’une synchronisation avec iTunes. Ils sont alors disponibles dans des fichiers .crash { l’adresse suivante :

C:\Users\<user>\AppData\Roaming\Apple Computer\Logs\CrashReporter\MobileDev ice\<device>\

C’est donc la partie server qui s’occupera de gérer les crashs log et de générer les rapports de bug.

En effet ces crashs log ne nous offrent pas assez d’informations pour remplir le fichier XML précédemment spécifié, nous allons recouper les informations des crashs log avec le rapport de bon fonctionnement générés juste avant, en comparant les date, comme le montre le schéma suivant.

(23)

22 | P a g e

Crash log généré par l’iPhone

Dernier rapport de bon fonctionnement au format

XML

Recoupage

Rapport de bug au format XML

FIGURE 8 RECOUPAGE DES RAPPORTS

Ainsi nous obtenons un rapport de bug au format XML exploitable pour l’apprentissage.

Pour les deux systèmes, les différents attributs à récupérer pour la génération du rapport seront par exemple : le nom du système, sa version, la mémoire disponible, l’état de la batterie, et l’état des différents réseaux (GSM/Wifi/Bluetooth/…).

3.3.3. Suivi de l’utilisateur

Un autre point a été soulevé lors de notre réflexion : la possibilité d’enregistrer les actions effectuées par un utilisateur sur l’appareil mobile.

Cela est faisable sous Android { l’aide des fichiers de journaux, listant très précisément les interventions sur l’appareil, ce qui n’est pas le cas sous iPhone, où l’on ne peut récupérer des fichiers logs qu’en cas de crash, et ne contenant pas les informations souhaitées.

3.3.4. Système expert

Nous avons choisi, pour ce système expert, de reprendre une structure similaire à celle du projet de l’année précédente. En effet, après étude, le choix d’un chainage avant pour l’aspect décisionnel semble pertinent, ainsi que celui d’une application légère.

(24)

23 | P a g e Notre système expert embarqué aura donc les caractéristiques suivantes :

 Il sera assez léger pour pouvoir fonctionner en tâche de fond, sans nuire à l’utilisation du mobile.

 Il sera capable d’anticiper les pannes de ce mobile de façon autonome, { l’aide de la base de règle précédemment calculée et fournie par le serveur.

 Une interface entre l’utilisateur et l’application contenant le système expert sera fourni, mais le logiciel tournera principalement en tâche de fond. Le système expert pourra tourner et diagnostiquer sans aide de l’utilisateur, mais chaque application d’une règle aura besoin d’une autorisation du propriétaire de ce mobile avant de s’appliquer. Ce diagnostic pourra se faire en temps réel, grâces aux informations de bon fonctionnement et de mauvais fonctionnement fournis par le mobile.

Grace { l’utilisation d’un format XML, toute la partie non embarquée, ainsi que les rapports seront similaires d’un mobile { l’autre. Le système expert, néanmoins, ne pourra pas l’être.

 L’application iPhone sera codée en Objective-C. En effet, peut de langage peuvent coder une application iPhone (C, JavaScript, Objective-C), et certaines librairies nécessaires { l’application n’existent que sous Objective-C. Nous avons donc choisit la langue la plus adapté : Objective-C.

 L’application Android, comme expliqué précédemment, sera codé principalement en Java. Langage le plus intuitif, et le plus utilisé pour des applications Android.

Dues aux caractéristiques propres à chacune de ces machines, le système expert se devra de fonctionner légèrement différemment d’un mobile { l’autre. La tâche de fond sur iPhone par exemple consistera en une application réveillée plus ou moins fréquemment par un mécanisme de géolocalisation, tandis que celle sur Android est gérée de façon plus simple par la machine.

Mais les fonctionnalités principales resteront tout de même presque identiques, au point que ces différences resteront invisibles { l’utilisateur externe.

Le système expert génère également des bilans sur l’utilisation des règles. Un fichier bilan consiste { répertorier les règles qui ont été proposés { l’utilisateur. Chaque règle sera représentée par son identifiant et on lui associera le nombre de fois qu’elle a été appliquée, le nombre de fois de fois où l’utilisateur a refusé de l’appliquer parce que jugée non efficace, et le nombre de fois qu’elle n’a pas été appliquée pour d’autres raisons. Ce fichier de bilan sera généré au format XML par le système expert, comme dans l’exemple suivant :

<rules>

(25)

24 | P a g e

</rule>

</rules>

(26)

25 | P a g e

4. Conclusion

Durant notre phase de spécifications, nous avons joué simultanément sur plusieurs fronts. Nous avons tenté d’identifier et de formaliser les besoins de la société Télélogos pour ce projet, afin de faire évoluer le projet de l’année passée. Parallèlement, nous avons continué l’étude de faisabilité nécessaire pour les applications Android et iPhone. Sur cette dernière, l’implémentation d’une telle application n’est pas évidente considérant les restrictions de l'iOS, et nous devions donc nous assurer des possibilités dont nous disposions afin d’y adapter nos spécifications précises.

Nous avons mis au point le nouveau principe de fonctionnement incluant : le système expert, le système de reporting, le module de surveillance des actions de l’utilisateur, l’apprentissage, et la définition de la communication entre ces différents modules.

Sur la partie mobile, les spécifications semblaient très simples, l’outil { développer étant identique { celui de l’année dernière. Nous avions donc pensé reprendre les spécifications à l’identique. Mais quatre problèmes sont survenus.

Premièrement, le choix fait l’année passée, de coder et d’envoyer les rapports en binaire est certainement la bonne chose { faire pour un produit devant être commercialisé. Cela n’est par contre pas approprié pour un prototype, demande beaucoup de temps de développement, et rend non lisibles les rapports échangés tant qu’ils ne sont pas décodés. D’où le choix cette année de passer par un format XML.

Deuxièmement, le fait de fournir les règles sous forme de dll pose le même type de problème avec en plus la nécessité d’avoir coté serveur les outils de compilation nécessaire, pour la plateforme cible. D’où le choix de passer cette année par le format XML.

Puis, nous avons rencontré, non pas réellement un problème, mais plutôt un imprévu : une discussion très récente avec Télélogos leur ont permis de nous faire la demande d’une fonctionnalité en plus : une option de suivi de l’utilisateur. Nous n’avons alors pas encore eu le temps de faire la spécification de cette demande.

Enfin, le dernier problème est le plus important. Suite à la pré-étude faite sur Android et sur iPhone, nous nous sommes aperçus qu’il n’existait pas sur ces systèmes d’équivalent de Dr Watson sous Windows mobile. L’information sur les plantages ne peut alors n’être remontée qu’{ partir des fichiers de log. Et dans ces derniers toutes les informations transmises dans le rapport de bon fonctionnement n’apparaissent pas. Nous en sommes donc arrivés { la conclusion que cette année les rapports de bons et mauvais fonctionnement auraient une

(27)

26 | P a g e structure différente. Maintenant il nous faut entièrement réfléchir { l’apprentissage en prenant en compte ces nouvelles données.

Sur la partie apprentissage, les cours n’ayant pas encore eu lieu, le temps passé depuis le rapport de pré-étude a été en partie consacré à continuer la pré-étude même. Les spécifications des formats des règles ont été entièrement faites. Celles des rapports de bon et de mauvais fonctionnement vont dépendre des informations ne nous arriverons à récupérer. Ils contiendront entre autre la mémoire, la liste des applications ouvertes, etc.

Cette spécification terminée, nous savons quoi faire et comment les différents modules s’organisent. Notre objectif est maintenant de dresser une planification concrète du projet. Nous y préciserons les différentes étapes à suivre et l'organisation choisie pour mener à bien les nombreuses évolutions spécifiées.

(28)

27 | P a g e

5. Bibliographie

1. iPuP. Programmez pour iPhone, iPod Touch, iPad avec iOS4. s.l. : Pearson, 2010.

2. Appcelerator, Inc. Appcelerator. [En ligne] [Citation : 21 10 2010.]

http://www.appcelerator.com/.

3. Xsysinfo - Display bar graphs of system load. Linux Software Directory. [En ligne]

[Citation : 27 Septembre 2010.] http://linux.maruhn.com/sec/xsysinfo.html.

4. WITTEN, Ian H. et FRANK, Eibe. Data Mining. s.l. : Morgan Kaufmann, 2005.

5. McEntire, Norman. How to use iPhone with Unix System and Library Calls : A Tutorial for Software Developers. How to use iPhone with Unix System and Library Calls. [En ligne] 18 Janvier 2009. [Citation : 27 09 2010.] http://www.servin.com/iphone/iPhone-Unix-System- Calls.html.

6. Guy, Romain. Painless threading. Android Developers. [En ligne] 2009.

http://android-developers.blogspot.com/2009/05/painless-threading.html.

7. Collins, Charlie. Android Application and AsyncTask basics. [En ligne] 2010.

http://www.screaming-penguin.com/node/7746.

8. Apple Inc. iOS Reference Library. [En ligne] 2010.

http://developer.apple.com/library/ios/navigation/.

9. Google. Android SDK. [En ligne] 2010.

http://developer.android.com/sdk/index.html.