Blog suivi par 3 abonnés

Et si on parlait 'agents intelligents' ?

Architecte
Val de Bagnes - Suisse
À propos du blog
Ma position sur les ‘agents intelligents’ (‘software intelligent agents’) ______________________________________________________ L’un de mes amis de 30 ans de vie, ancien président de commission(s) informatique)(s)1… nationale(s) suisse(s), me pose des questions sur l’élaboration d’une immense base de données de réparation de centaines ou milliers de pièces incluant des centaines ou milliers de processus … je lui réponds en énonçant l’état de l’art dans le domaine des ‘agents intelligents’ qui précisément permettent d’élaborer automatiquement puis de maintenir automatiquement une telle base de connaissances auto-apprenante. Mise sur pied d’une large base de données de Maintenance Tout le monde utilise des bases de données, google (très large), ou l’annuaire téléphonique (moins large) ou sa propre liste de contacts sur son ordinateur ou son téléphone portable de 300 à 2 000 personnes par exemples (c’est comme cela que nous appelons nos proches sans nous souvenir de leurs numéros de téléphones). Mais comment faire quand on veut utiliser et maintenir une base de données pour disons … réparer des milliers d’objets ? N’importe qui comprend que l’on va au devant d’une liste d’éléments et de relations (les deux ensembles constituant une définition d’une base de données) qui sera large à passablement large. Donc il faut s’équiper et avoir même des automatismes de maintenance de ladite liste. Ces automatismes sont nommée agents intelligents ou ‘robots’ de recherches. ‘Ouvrons le capot du moteur’ et voyons comment va fonctionner cette programmation de notre base de données universelle de maintenance : – il faut lister les éléments par objet ou par familles … en html5 si possible car le mode de questionnaire ouvert des étapes de conception et l’indépendance à une marque, un système ou un type d’ordinateur est très favorable pour la pérennité du système; – sur cette architecture générale de la base de données, il faut greffer l’alimentation des détails ou des mise à jours des nouvelles pièces de remplacement ou de nouveaux fabricants : ici on va employer des ‘agents intelligents’ (programmation légère en java – système ouvert lui aussi); ils sont programmables en quelques lignes seulement (même un non informaticien peut y arriver); – les agents recherchent automatiquement sur tout internet (eh oui !) le type de de données qu’ils doivent recueillir (cela paraît incroyable, c’est pourtant vrai); il y a des dizaines de milliers de destinataires de telles requêtes … donc des milliers de requêtes (pour des pièces de machine à coudre, de machines à laver, de mixers …), lesdites requêtes qu’il faudra d’ailleurs rédiger ou que l’on émettra grâce à un questionnaire en ligne mis à jour sur le générateur des agents (donc les requérants rédigeront les requêtes); – et ces milliers de requêtes vont à des milliers de sites sur internet (donc par produit croisé des millions d’actions résultantes); – il reste à définir le taux de ‘rafraîchissement’ des données ou la fréquence de ces recherche et leur mise à jour : vu les dizaines de milliers de requêtes et leurs millions de retours, expérience faite dans d’autres cas, nous préconisons deux fois par semaine pour commencer (cela suffit aux utilisateurs de la base de données et aussi aux fabricants, c’est quand même plus d’une centaine de mises à jour par an). Quand le système se met en place et démarre, il enfle tout seul et se maintient tout seul (pas vraiment, il y aura évidemment des tas de problèmes à régler, c’est naturel) : c’est son architecture de base qui doit être bien réglée. Ensuite on apporte des améliorations ‘incrémentales’ (par étapes). Calendrier : a. mise en place rudimentaire version 0.5 jusqu’à 0.9, quelques centaines d’objets courants, quelques dizaines de processus et pièces manquants : 3-6 mois; b. déploiement du système version 1.0 : un an (dans la transition vers le 1.0 on fonctionne avec les versions 0.9); c. augmentation des cas à plusieurs milliers d’objets par plusieurs milliers de processus et pièces : version 2.0 au bout de deux ans (un an après la sortie de la version 1.0). d. succès international avec la version 3.0 dès la troisième année, qui permet le soutien dynamique et actif d’un réseau de franchisés ou co-traitants. Voilà c’est tout. Je pense que ma contribution amicale est un solide coup de pouce à notre ami comme François. J’ai des quantités de présentations pdf à ce sujet réalisées par un de mes associés informaticiens. Je peux aussi les mettre en ligne ou indiquer les liens. Qu’en pensez-vous ? - Ici mon interlocuteur me dit vouloir mettre sur pied une base sous forme de catalogue d’images. Il faut préciser la position. Oui ce n’est pas mal, mais tu/vous vous situez encore dans la lignée des manuels de réparations de l’avionique des années 1970-1990 ou pour nous rapprocher du parc à réparer des photocopieurs des mêmes années. Le défaut de la démarche que je vois, sans vouloir critiquer, mais qui causera du retard au bon développement de la base de données, est le caractère livresque, anciennement éditorial. Sympathique mais trop long à parcourir pour des non intellectuels. Aussi pour des intellectuels. Je parle d’une base de donnée sémantique, avec orientation ‘objet’, des descripteurs par ‘éléments’ non par tiff ou jpeg (représentations sympathiques, mais à nouveau dépassées). on parle de BIM ou de workflow GPAO ou FAO (je travaille en BIM depuis plusieurs années). Par la suite, avec les agents intelligents tu maintiens au moins une base de liens (sémantiques) de la problématique de réparation ou des moteurs émulant les images ‘orientées objets’ des pièces et leurs identités (accolée / tags) considérées comme des ‘entités’ digitales. Il y a une différence de niveaux stratégiques entre ce que tu proposes et ce que je décris. Les deux niveaux ont leur qualité, je parle d’un autre niveau que le tien. C’est là que je situe mon/notre intervention possible avec social-IN3.coop . Sinon pour la base de premier niveau, la ‘vôtre’ je serai volontiers sous-traitant fournisseur pour des fournitures d’images qui viendraient à vous manquer, ou vues sous un autre angle (que je conserverai en objets pour leur édition possible dans le 2ème niveau par la suite). - ‘REALITYCHECK ‘(plusieurs voix, on est sur un forum) : Mais je suis aussi ouvert aux innovations que je comprends. Alors merci de m’expliquer avec des mots simples comment décrire de manière univoque une pièce (éventuellement générique, càd utilisable dans plusieurs types d’appareils). Il faut encore préciser, donc un coup de zoom de plus. Normal, nous sommes en Suisse. Et les Helvètes veulent du concret … Pour les objets utilisons un format ‘objet’ universel (ifc dans la construction par exemple ou 3ds dans les logiciels CFAO ou 3d universels, que l’on ouvre aussi en sketchup, gratis en version démo), ensuite on retombe sur les exports jpeg et autres. Et je disais que comme toute pièce avait sûrement déjà été saisie par d’autres acteurs de bases de données, on mettait d’abord les liens sur les fichiers existants (aussi en jpeg) avant de les redessiner. Donc des liens avant des objets, puis des objets et si on a le budget financier, etc. donc le temps de les exécuter (les ‘faire’) on les réalise, et ensuite on définit les exports désirés dans les formats images désirés. - Tu as toujours trois longueurs d’avance! Je suis allé faire un tour du côté de http://www.social-in3.coop/en/. Mais je n’arrive pas à comprendre de quoi il retourne concrètement et encore moins quel pourrait être l’apport pour mon projet (un peu trivial) d’encyclopédie des appareils et des composants … L’innovation doit être expliquée … Je donne des liens http://www.social-in3.coop/…/IN3_BIM_LesAgentsInformat... [PDF]Point de situation projet musée – Social-IN3 http://www.social-in3.coop/…/IN3_BIM_LesAgentsInformat... Et ensuite je cite un travail de diplôme de trois ans d’âge où j’étais expert en bases de connaissances. Quelques explications issues d’un diplôme où j’étais l’expert des déplumant Miguel Tavares dos Santos, Professeur Johann Sievering Vers la fin du document je vous ai mis la copie d’un ‘string’ java très court qui permet déjà des requêtes (moins de 5 lignes !). ___________________________________________________________ Introduction Agent Oriented Programming (AOP) en français : programmation orienté agent, est une façon de programmer un système qui doit être autonome, mobile et distribué. Cette manière de programmer modélise le système comme une collection de composants appelé agents qui sont caractérisés par l’autonomie, la capacité de communiquer, la proactivité et l’introspection. En étant autonome, ces agents peuvent être amenés à gérer des tâches complexes souvent sur du long terme. La proactivité leur permet de prendre la décision de commencer une tache sans avoir besoin d’un ordre de la part d’un utilisateur. La capacité de communication permet une interaction avec d’autres agents qui permettra ainsi d’atteindre un but commun ou personnel. L’introspection permet à l’agent d’être conscient de son état. (…) Lors du développement d’application, on essaye de répondre à un besoin spécifique dans un environnement défini. La sémantique de l’ensemble des composants et les types de données ne sont connus qu’à l’intérieur de cet environnement, ce qui confine alors l’utilisation de cette application uniquement dans son domaine et pour les fonctionnalités prévues explicitement. Ce qui est recherché pour palier à cette problématique, c’est une définition sémantique de plus haut niveau qui permettrait à des systèmes automatiques de traiter avec plus de finesse les données ainsi qu’une possibilité d’enrichir les comportements afin d’adapter dynamiquement ceux-ci selon le contexte opérationnel. Dans notre projet, nous souhaitons mettre en place un Bus Orienté Agent qui nous permettra, indépendamment des technologies, la mise en place, d’échanges d’informations dans le domaine du patrimoine et les musées. (…) 2.4 Technologie Pour le développement de cette architecture, nous avons considéré un système d’information asynchrone avec des agents informatiques. Il est donc nécessaire que chaque composant soit autonome et qu’il puisse accomplir ses tâches même dans l’éventualité où la communication serait perdue. La plateforme multi-agent répond parfaitement à ces critères. En effet, elle nous permet de garder le même sens sémantique pour un objet tout au long de son parcours à travers les différentes couches. Il est aussi nécessaire que ces agents aient la capacité d’enregistrer leur profil sémantique dans la base de connaissance. En effet, les agents ont la capacité de s’appeler entre eux pour la recherche de compétences. Afin que cette recherche soit possible, chaque agent inscrit ses compétences dans un annuaire commun telles les pages jaunes. Nous avons choisi JADE (Java Agent DEvelopment framework) pour mettre en œuvre la plateforme multi-agents. Cette plateforme est entièrement écrite en Java et elle propose des outils de développement et d’administration. Le protocole de communication http correspond à ce que nous voulons faire dans notre projet. De plus, elle est compatible avec les standards FIPA. Nous pourrons donc utiliser le langage ACL (langage de communication agent). Chaque acte de langage est composé : d’un performatif, de l’expéditeur, du destinataire et du contenu relatif au performatif. D’autres informations complémentaires sont aussi disponibles dépendant de l’utilisation de l’acte de langage souhaitée. (…) FIPA FIPA (Foundation for Intelligent Physical Agents) en français : fondation pour l’intelligence physique des agents, est une organisation à but non lucratif. Créée en 1996, son but est de produire des standards pour l’interopération d’agents logiciels hétérogènes. Grâce à la combinaison d’actes de langages, de logiques des prédicats et d’ontologies publiques, cette organisation veut mettre à disposition des moyens standardisés qui permettent d’interpréter les communications entre agents de telle façon que l’on respecte leur sens initial. Les différents domaines où l’on peut avoir des standards donné par la FIPA sont :  Les applications (applications nomades, agent de voyage personnel, applications de diffusion audiovisuelles, etc.) ;  Les architectures abstraites, définissant d’une manière générale les architectures d’agents ;  Les langages d’interaction (ACL), les langages de contenu (comme SL, CCL, KIF ou RDF) et les protocoles d’interaction ;  La gestion des agents (nommage, cycle de vie, description, mobilité, configuration);  Le transport des messages : représentation (textuelle, binaire ou XML) des messages ACL, transport (par IIOP, WAP ou HTTP) de ces messages. Ces standards sont toujours mis à jour. La FIPA ne veut pas créer une plateforme de construction multi-agents, elle cherche à normaliser la plateforme de sorte que lors de l’exécution, on bénéficie d’un système interopérable. Actuellement, le nombre de membre de la FIPA s’élève à 608, ce qui représente environ 17 pays à travers le monde. (…) 4.2 PlateformeJADE 4.2.1 Introduction JADE (Java Agent DEvelopment Framework) est une plateforme entièrement implémenté en Java qui permet la mise en place de Système Multi-Agent (SMA). JADE est une instance de la FIPA (Foundation for Intelligence Physical Agent) et fournit une multitude de classes qui implémentent le comportement des agents qu’elle crée. Pour utiliser cette plateforme nous avons le choix de la lancer à la ligne de commande et ensuite de créer les classes java depuis un éditeur de code source (EditPlus, NotePad++, etc.) ou d’utiliser un environnement de développement intégrer (IDE). Afin de réaliser ce projet, l’option de l’IDE a été retenue. 4.2.2 Architecture logiciel JADE se base sur le modèle d’architecture fournit par la FIPA, l’Agent Management Reference Model. Il établit le modèle de référence logique pour la création, l’enregistrement, la localisation, la communication, la migration et l’arrêt des agents. Dans la figure ci-dessous, nous pouvons voir plusieurs éléments que l’on va appeler services. Les services dont on dispose à la base sont le Directory Facilitator (DF) et l’Agent Management System (AMS). Il est bien sur possible de demander le chargement au démarrage du Message Transport System (MTS) pour permettre la communication entre plusieurs plates-formes, mais le modèle de base ne le fait pas afin de garder par défaut les fonctionnalités adapté à tout type d’utilisation du modèle. (…) 4.3 LesAgents Un Agent JADE est un thread en JAVA. Il possède des comportements ‘implémentant’ des services ou des fonctionnalités et suit un cycle de vie suivant : Figure 4 Cycle de vie d’un agent JADE Un Agent JADE hérite de la classe Agent. Il a la possibilité de s’inscrire ou de rechercher un service. Un service peut être  Une action enregistrée et délivrée par la plateforme  Un comportement d’un ou plusieurs agents répondant à la demande  Gérer par des « pages jaunes » (DF)  Semblable à la notion de Web Services L’Agent JADE possède une méthode setup() qui est invoquée dès la création de l’agent et une méthode takedown() appelée avant qu’un agent ne quitte la plateforme (passe à l’état « détruit »). (…) A chaque envoi de message, l’agent créé un nouvel objet de type ACLMessage. Ensuite pour procéder à son envoie, il faut utiliser la méthode send(), en français : envoie. Si un agent veut recevoir un message, il doit alors utiliser la méthode receive(), en français : recevoir ou au contraire le bloquer avec la méthode blockingreceive() en français : bloquer réception. Afin de rechercher ou modifier les champs de l’objet ACLMessage, l’agent utilise les méthodes set() et get() en français respectivement modifier et obtenir. La communication des messages se fait de manière asynchrone (la communication ne se passe pas à la même vitesse pour tous les agents). Le tableau ci-dessous présente les champs disponibles dans un message ACL. Tableau 1 Message ACL Performative : type de l’acte de communication Sender expéditeur du message Receiver destinataire du message reply-to participant de la communication content contenu du message language description du contenu encoding description du contenu ontology description du contenu protocol contrôle de la communication conversation-id contrôle de la communication reply-with contrôle de la communication in-reply-to contrôle de la communication reply-by contrôle de la c (…) Pour créer un agent, nous avons soit la possibilité de choisir une classe générique dans la librairie des classes ou créer notre propre classe agent. Pour cette démonstration, je vais créer une classe agent qui sera en charge d’écrire dans le log « Bonjour ! Je suis nomAgent ». Pour ce faire voici la classe créé10 : public class HelloAgent extends Agent { // Première méthode exécutée lors du lancement de l’agent protected void setup() { System.out.println(« Bonjour! Je suis  » + getLocalName()); doDelete(); } // setup fin } // HelloAgent fin (…) (fin de citation) REMARQUE WASSERFALLEN mais en profondeur cela donne plutôt DES REQUÊTES DE CENT à DEUX CENTS LIGNES pour des requêtes plus complexes.
Mots-clés