Méthode du recueil de connaissances expertes

Méthode du recueil de connaissances expertes

Le POD Mildium, même sous sa forme initiale aux spécifications largement incomplètes (voir ann. B), est une ébauche de processus décisionnel. Il s’agissait donc de faire un recueil du processus. Je n’ai pas abordé ce sujet comme un problème de spécification classique en génie logiciel puisqu’il ne s’agissait pas, dans mon cas, de concevoir un système pour résoudre un problème mais bien, dans un premier temps de retranscrire de manière exhaustive et fidèle, la solution mise au point par les pathologistes (les experts). C’est seulement dans un second temps que l’on se proposait de compléter cette solution par une plus grande richesse de détails. Notons néanmoins, en ce qui concerne le recueil d’exigences et la spécification formelle pour le génie logiciel, les travaux de Glinz (Glinz, 2002; Glinz et al., 2002) qui définissent un idiome des Statecharts adapté à la représentation des exigences, ainsi que ceux de Svetinovic et al. (2007) qui développent une critique de la méthodologie d’analyse des systèmes par Statechart (mise au point d’un protocole « Vo-ip » dans leur exemple). Ces deux démarches se concentrent sur l’utilisation des Statecharts pour la spécification de systèmes entiers. Ce type d’approche est nettement minoritaire depuis la généralisation de l’approche de la programmation orientée objet et la généralisation d’UML 2.0 b . En effet le Statechart qui, dans l’approche fonctionnelle de ses origines, pouvait servir à spécifier l’ensemble du système (Harel, 1987) est dans UML 2.0 utilisé pour décrire le comportement d’une classe. Notre plate-forme de simulation utilisant un langage à objet (C++), le POD est modélisé par un Statechart et une classe UML 2.0 unique. Notre objectif est ici de décrire le plus fidèlement possible le comportement décisionnel des experts avec ce Statechart. 4.2 Matériel et méthodes Matériel et méthodes sont présentés de manière complète en section 4.4.3.1. Le recueil de connaissances a été effectué auprès de quatre Experts. – les entretiens duraient environ une heure – le recueil a été effectué sur la base d’un diagramme Statechart. – du papier calque et un crayon ont été utilisés pour annoter les diagrammes. – les entretiens étaient enregistrés avec le logiciel Audacity.

Présentation de l’article 

L’article se compose de la manière suivante : l’introduction replace d’abord les SED dans le contexte de la modélisation de processus de production agricole « industriels » a. le 17/08/2008 b. Unified Modelling Language (UML 2.0) voir http://www.omg.org CemOA : archive ouverte d’Irstea / Cemagref comme l’un des cadres utilisés (notamment via les DEVS c de Zeigler et al., 2000). Ensuite sont présentées les motivations présidant à la conception de Mildium, c’est à dire principalement le besoin d’innovation dans le domaine de la protection des cultures en viticulture (voir chap. 1), ainsi que les objectifs de la formalisation : le besoin d’une explicitation de l’intégralité de la connaissance mise en œuvre par les experts pour pouvoir passer à une étape d’expérimentation plus large et mener des simulations dans le cadre d’une ferme virtuelle. L’introduction se termine par le choix du formalisme Statechart, cette section reprenant en condensé les éléments présentés au chapitre 2 à la section 2.6. Dans un deuxième temps, les enjeux puis les objectifs de l’article sont précisés : L’une des difficultés pour la formalisation du POD Mildium réside dans le fait qu’il s’agissait d’un travail d’équipe. Les membres de l’équipe s’accordaient sur les caractéristiques les plus importantes mais il existait de nombreuses différences sur l’interprétation des détails. Au cours des expérimentations de plein champ, la prise de décision s’est effectuée collégialement. Afin d’expliciter l’ensemble de la connaissance du processus, il m’a semblé que j’obtiendrais une richesse de détails plus grande en procédant à l’extraction de connaissances auprès de l’équipe entière, plutôt que de sélectionner l’un d’entre eux et de ne recueillir que sa compréhension du processus. Les membres de l’équipe avaient conçu le POD Mildium ensemble et cela aurait été une perte de ne pas tirer avantage de l’apport de chaque expertise spécialisée. Objectifs de l’article : La problématique peut être exprimée ainsi : après avoir conçu une solution PIC pour le contrôle du pathosystème viticole en utilisant une connaissance experte et avoir identifié les Statecharts comme un formalisme de modélisation pertinent, peut on utiliser ce même formalisme pour extraire la connaissance ? En d’autres termes : est-il possible de procéder à un recueil de connaissances, en utilisant des Statecharts comme médiation entre le « cogniticien » d et de multiples experts ? L’article explore cette question en trois points, (i) en exposant un état de l’art du recueil de connaissances auprès de multiples experts puis, (ii) en présentant la méthode à proprement parler suivie d’une illustration des résultats, enfin (iii) en précisant l’une des méthodes de validation mise en œuvre. Une discussion en forme de retour d’expérience clôt ce travail. c. Discret EVent System(DEVS) d. en anglais Knowledge Engineer CemOA : archive ouverte d’Irstea / Cemagref 4.4. 4.4 Article « expérimentation des Statecharts pour le recueil d’une connaissance agronomique auprès de multiples experts » Remarque : L’expression POD Mildium est traduite en anglais par : Grapevine powdery and downy Mildew Decision Workflow System (GrapeMilDeWS) . CemOA : archive ouverte d’Irstea / Cemagref Article soumisà Expert Systems with Applications le 17/08/2008. Experimenting Statecharts for Multiple Experts Knowledge Elicitation in Agriculture e Bertrand Léger*,$ and Olivier Naud* *Cemagref – UMR ITAP – BP 5095 34196 Montpellier Cedex 5 $ INRA – UMR Santé Végétale -BP 81 33883 Villenave d’Ornon Cedex Abstract Statecharts were experimented as a mediation tool between multiple experts and a knowledge engineer. After a short survey of knowledge elicitation methods for multiple experts, we present our method for assessing the quality of the elicited model and give critiques on the basis of our case study in vineyards crop protection management. 

Introduction

 Environmental as well as health issues are getting growing consciousness among the public. Designing processes for sustainable agriculture is therefore a major research goal. Agricultural production processes have been analysed as industrial processes for almost 20 years now (Sebillote and Soler, 1988). In this context, a tradition for agricultural production process simulation has grown, for example (Attonaty et al., 1994; Cros et al., 2001; Bakam et al., 2001). Many paradigms have been used for this purpose including discrete event system specification (DEVS) (Cournut and Dedieu, 2004). If Ziegler’s DEVS (Zeigler et al., 2000) is a well known formalism for simulation, DES (for discrete event system) formalisms have also been shown to be suitable for qualitative analysis and control of various systems (Lunze, 2000). Our research goal is to represent decision making in crop protection. Although most decision support systems in agriculture are rule based (Shaffer and Brodahl, 1998), our approach is process based and expertise based. We call it a decision workflow system (DeWS). We present here a design aid method for modelling expert decision making procedures, with a representation that belongs to the family of DES formalisms. 

Rationales for the case study 

The present case study deals with French vineyard. Vine growers consume about 25% of the pesticides used in France while vineyards’ total area is 3% of the French farmland. Growers have developed intensive and mostly preventive crop protection techniques, because the high quality vine cultivar are highly susceptible to fungal pathogens and outbreaks are difficult to handle. Although pesticide use reduction efforts have been carried e. Some materials used in the present article have been presented previously at the IFAC-MCPL2007 conference. CemOA : archive ouverte d’Irstea / Cemagref out, further development toward sustainable viticulture requires innovative protection methods. Integrated Pest Management (IPM) is one of those. IPM aims at reducing the amount of inputs while keeping the revenue of farms, through the use of biological control as well as pesticides when necessary (Kogan, 1998). Unfortunately, so far no biological agent has been made available against the main fungal pathogens to satisfy the production targets and the complexity of the grapevine pathosystem (i.e. crop + pathogen + climate). In addition, current lack of detailed epidemiological knowledge does not allow computation of optimal solutions for the design of minimal pesticide strategies. Therefore, pest management procedures need to be designed based on expertise. An expert based IPM solution was designed by a team of phytopathologist experts from INRA plant health research unit (Bordeaux). We named it “GrapeMilDeWS” (Grapevine powdery and downy Mildews Decision Workflow System). GrapeMilDeWS aims at controlling two of the prevailing vineyard diseases: powdery mildew (Erysiphe necator) and downy mildew (Plasmopara viticola). It is based on the following hypothesis: knowledge and information can help to substitute numerous and systematic treatments. GrapeMilDeWS was originally described with a set of guidelines, relying to a large extent on the personal (implicit) knowledge of its expert designers for implementation. It was experimented in the vineyard and demonstrated its efficiency with satisfactory harvest results and reduced number of phytopharmaceutical treatments (Cartolaro et al., 2007). Formalising this DeWS should allow all necessary hidden knowledge to be made explicit. Modelling had indeed two objectives. First, the formal model would allow others phytopathologist to implement the decision process, thus permitting large scale experimentations. Second, a formal model can be used for computer simulations not only at the process’ plot level but also at the farm level, for instance, to check for resources use, workload and induced costs at a larger scale. Finally, the formalisation process should also provide reflexive insight to the designer, allowing them to explore new design alternatives. 

Choice of formalism 

In GrapeMilDeWS, the continuous behaviour of the pathosystem controlled by the crop protection process, are discretised in abstract variables which encode for low, moderate and high disease risk. Thus fed with discrete input, GrapeMilDeWS is modelled as a DES. GrapeMilDeWS includes the user (or human being) in the control loop. For instance, the disease level are evaluated by workers in the vineyard. This information is aggregated in synthetic discrete values. In reaction to external events, transitions are fired, which generate internal and output events. The output events are decisions for action to be carried out on the system by human operators. We chose to represent GrapeMilDeWS using a graphical language, i.e. Statechart, introduced in (Harel, 1987). As said by Harel, Statecharts can be described as enriched finite state automata (FSA): statechart= state-diagrams + depth + orthogonality + broadcast-communication CemOA : archive ouverte d’Irstea / Cemagref– State-diagrams are graphical FSA in the sense of both Mealy and Moore machines (Harel and Pnueli, 1985). – Depth is the capacity of hierarchically encapsulating a statechart inside a state; this enable us to avoid confusing details and to get a more abstract view. – Orthogonality is the ability to represent multiple concurrent processes in the same statechart, which is the main feature of statechart responsible for preventing the exponential growth of the state space as the systems complexity increases. – Broadcast communication represents the way events are made available simultaneously to all elements of the statechart. This feature is powerful although it leads to formal difficulties in the implementation which are generally managed through various “flavours” of pseudo-synchronicity of the events (Maggiolo-Schettini et al., 2003). The original version of statechart, was implemented with broadcast communication over the whole system. However, in the UML object oriented version of statecharts, the inter-object communications are point to point (Damm et al., 2003). We used Telelogic’s Rhapsody statecharts (Harel and Kugler, 2004) for our modelling. Rhapsody implements a variant of the UML object semantic of statecharts. As all versions of statecharts are not equivalent, one should refer to (Crane and Dingel, 2007) and for an earlier, exhaustive view of statechart variants to (von der Beeck, 1994). 

 A team work design

 One of the difficulties for the formalisation of GrapeMilDeWS was that the design was a team work. The team members agreed upon the most important features, but there were many differences in their interpretation of the details. During the field experiments the decision making was done collegially. In order to make all of the process’ knowledge explicit, it seemed that we would get richer details if we elicited the whole team, instead of singling out one of them and capturing his understanding of the process. They had designed GrapeMilDeWS together and it would have been a loss not to capture each specialized expertise’s input.