Login| Sign Up| Help| Contact|

Patent Searching and Data


Title:
DISPLAY CONFIGURATION-RECONFIGURATION METHOD FOR A SET OF DISPLAY DEVICES
Document Type and Number:
WIPO Patent Application WO/2007/042477
Kind Code:
A3
Abstract:
The invention relates to systems provide with control devices comprising an important number of displaying devices for displaying an important number of parameters according to accurate configurations, as for example, a modern aircraft instrument panel provided with several displays. The inventive method for configuring or reconfiguring the totality of displaying devices consists in inducing said configuration or reconfiguration by an event. Each elementary configuration is substantially obtainable by means of a reconfiguration logic language and an interpreter algorithm, wherein said logic language substantially comprises a reconfiguration domain, properties, transition rules, and preferences and said interpreter algorithm makes it possible to convert each transition rule into a list of elementary reconfiguration.

Inventors:
BONNET DENIS (FR)
CAPELLE BRUNO (FR)
LE ROUX YANNICK (FR)
MICHEL FRANCOIS (FR)
Application Number:
PCT/EP2006/067140
Publication Date:
July 24, 2008
Filing Date:
October 06, 2006
Export Citation:
Click for automatic bibliography generation   Help
Assignee:
THALES SA (FR)
BONNET DENIS (FR)
CAPELLE BRUNO (FR)
LE ROUX YANNICK (FR)
MICHEL FRANCOIS (FR)
International Classes:
G06F9/44
Other References:
BASTIDE REMI; PALANQUE PHILIPPE: "A Petri net based environment for the design of event-driven interfaces", PROCEEDINGS OF 16TH INTERNATIONAL CONFERENCE ON APPLICATIONS AND THEORY OF PETRI NETS 26-30 JUNE 1995 TORINO, ITALY, 26 June 1995 (1995-06-26), Springer-Verlag Berlin, Germany, pages 66 - 84, XP002474162, ISBN: 3-540-60029-9, Retrieved from the Internet [retrieved on 20080327]
XIAOSONG LI ET AL: "Petri net based graphical user interface specification tool", SOFTWARE EDUCATION CONFERENCE, 1994. PROCEEDINGS. DUNEDIN, NEW ZEALAND 22-25 NOV. 1994, LOS ALAMITOS, CA, USA,IEEE COMPUT. SOC, 22 November 1994 (1994-11-22), pages 50 - 57, XP010150733, ISBN: 0-8186-5870-3
LI XIASONG ET AL: "A PETRI NET-BASED ENVIRONMENT FOR GUI DESIGN", 1997 IEEE INTERNATIONAL CONFERENCE ON SYSTEMS, MAN AND CYBERNETICS: COMPUTATIONAL CYBERNETICS AND SIMULATION. ORLANDO, FL, OCT. 12 - 15, 1997, IEEE INTERNATIONAL CONFERENCE ON SYSTEMS, MAN AND CYBERNETICS. CYBERNETICS, NEW YORK, IEEE, US, vol. VOL. 3, 12 October 1997 (1997-10-12), pages 2234 - 2239, XP000787516, ISBN: 0-7803-4054-X
KURT LAUTENBACH ED - WIL M P VAN DER AALST ET AL: "Logical Reasoning and Petri Nets", APPLICATIONS AND THEORY OF PETRI NETS 2003 LECTURE NOTES IN COMPUTER SCIENCE, SPRINGER BERLIN HEIDELBERG, BE, vol. 2679, 1 January 2003 (2003-01-01), pages 276 - 295, XP019053809, ISBN: 978-3-540-40334-0
Attorney, Agent or Firm:
BREDA, Jean-Marc et al. (Conseils en Propriété Industrielle31-33 Avenue Aristide Briand, Arcueil Cedex, FR)
Download PDF:
Claims:

REVENDICATIONS

1. Procédé de configuration et de reconfiguration d'une pluralité d'affichages appelés « formats » sur un ensemble de dispositifs de visualisation appelés « visus », la reconfiguration d'une configuration initiale étant induite par une cause appelée « événement » pour aboutir à une configuration finale, caractérisé en ce que chaque configuration est obtenue essentiellement au moyen d'un langage logique de reconfiguration et d'un algorithme d'interprétation, ledit langage logique comprenant :

• Un domaine de reconfiguration : ensemble d'éléments comprenant principalement o des places modélisant principalement les visus ; o des jetons modélisant principalement les formats ; o les événements ; o les fonctions logiques qui unissent les places, les jetons et les événements ;

• Des propriétés : ensemble de règles définissant les configurations acceptables ;

• Des règles de transition : ensemble de règles définissant les reconfigurations acceptables ;

• Des préférences définissant un ordre de calcul et des formats prioritaires sur les visus ; et le dit algorithme d'interprétation permettant de transformer chaque règle de transition en une liste de reconfigurations finales.

2, Procédé selon la revendication 1 , caractérisé en ce que les propriétés sont définies par des formules logiques construites à partir des éléments du domaine de reconfiguration, de comparateurs et d'opérateurs booléens.

3. Procédé selon la revendication 1 , caractérisé en ce que les règles de transition sont composées de trois éléments : • Un événement ;

• Une garde : formule logique qui définit l'ensemble des configurations initiales possibles avant l'événement ;

• Une conclusion ; formule logique qui définit l'ensemble des configurations finales possibles après l'événement.

4. Procédé selon la revendication 1 , caractérisé en ce que les règles de transition comportent des variables, une variable regroupant un ensemble de places ou de jetons.

5. Procédé selon la revendication 3, caractérisé en ce que certaines règles de transition sont dites impératives, c'est-à-dire qu'elles doivent s'exécuter sans conditions.

6. Procédé selon la revendication 3, caractérisé en ce que certaines règles de transition sont dites optionnelles, c'est-à-dire qu'elles doivent s'exécuter à la condition de ne violer aucune propriété.

7. Procédé selon la revendication 1 , caractérisé en ce que les préférences définissent : • L'ordre de calcul des places ;

• L'ordre de préférence des jetons sur les places.

8. Procédé selon l'une des revendications précédentes, caractérisé en ce que l'algorithme d'interprétation comprend une première étape de mise en forme appelée expansion dans laquelle :

• Les formules logiques des propriétés sont transformées en clauses disjonctives, suite d'égalités ou d'inégalités entre les éléments du domaine de reconfiguration séparées par les opérateurs logiques « ou » ; • Les gardes et les conclusions des règles de transition sont transformées en clauses conjonctives, suite d'égalités ou d'inégalités entre les éléments du domaine de reconfiguration séparées par les opérateurs logiques « et », un couple composé d'une garde et d'une conclusion sous la forme de deux clauses conjonctives étant appelé noeud initial, les

différents nœuds initiaux étant stocké dans une liste appelée liste initiale ;

• Les variables sont remplacées par leurs valeurs.

9, Procédé selon la revendication 8, caractérisé en ce que l'algorithme d'interprétation comprend une seconde étape d'interprétation des noeuds initiaux en nœuds finaux, ladite seconde étape comportant les sous-étapes suivantes :

• Création d'une seconde liste ce nœuds à partir de la liste initiale, les nœuds de cette seconde liste vérifiant la propriété suivante : si la garde du nœud vérifie toutes les propriétés du système, alors la conclusion du nœud vérifie toutes les propriétés du système ;

• Création d'une troisième liste ce nœuds à partir de la seconde liste, la conclusion des nœuds de cette troisième liste ne possédant plus d'inégalités ;

• Création d'une liste finale à partir de la troisième liste, les gardes des nœuds de cette liste finale étant exclusives.

Description:

PROCEDE DE CONFIGURATiON-RECONFIGURATIQN D'AFFICHAGE POUR UN ENSEMBLE DE DISPOSITIFS DE VISUALISATION.

Le domaine de l'invention est celui de systèmes comprenant des organes de contrôle ou de commande possédant un ensemble important de dispositifs de visualisation devant afficher un grand nombre de paramètres selon des configurations précises afin, par exemple, que certaines informations vitales pour le fonctionnement ou la sécurité du système soient toujours affichées de la façon la plus ergonomique possible.

Le domaine d'application privilégiée est l'aéronautique. En effet, les planches de bord des aéronefs modernes possèdent à la fois un grand nombre d'écrans de visualisation que l'on appellera indistinctement dans la suite du texte « visu » ou encore « display » et un grand nombre d'affichages différents que l'on appellera également « format » dans la suite du texte.

Ainsi, la planche de bord d'un Airbus A380 possède 8 écrans principaux et une dizaine de configurations possibles par écran. La figure 1 montre un exemple d'affichages dans un cockpit d'Airbus A380. Les 8 visus sont appelées respectivement L1 , L2, L3, C1, C2, R1 , R2 et R3. En général, un format n'est pas propre à une visu particulière : il peut être affiché successivement ou simultanément sur plusieurs visus différentes. Le format dit PFD, acronyme anglo-saxon signifiant Primary Flight Display est un format fournissant toutes les données primaires de vol au pilote comme l'altitude ou le cap. Dans l'exemple de la figure 1 , le format PFD est affiché à la fois par les visus L1 et R1. Les panneaux de commande CPL et CPR figurant sur la figure 2 permettent au pilote d'intervenir pour sélectionner, entrer et modifier les informations affichées.

Cette invention peut cependant être appliquée à d'autres domaines techniques ou industriels comme les salles de contrôle ou de commandement possédant des ensembles importants de dispositifs de visualisation et nécessitant un niveau de fiabilité et de sécurité importants.

Dans le cas d'une planche de bord d'aéronef, on doit pouvoir facilement configurer ou reconfigurer les formats affichés sur les visus afin ;

• D'assurer la disponibilité des fonctions critiques, vitales pour Ie pilotage ou la navigation ;

• D'adapter la configuration du cockpit à la mission ou à la phase de vol souhaitée. On entend par configuration un état de la planche de bord définissant les formats affichés sur chaque visu et par reconfiguration un changement d'état de la planche de bord liée à un événement.

Actuellement, la gestion des configurations-reconfigurations des formats est assurée par une table de configuration à double entrée. La première entrée donne les événements susceptibles d'entraîner une reconfiguration et la seconde entrée donne la configuration retenue en fonction de l'événement survenant.

Ce procédé reste efficace tant que le nombre d'événements ou de configurations reste limité. Sur les aéronefs modernes, le nombre d'événements possibles a crû de façon importante. Il peut survenir :

• Des pannes d'équipements concernant les visus ou les calculateurs de bord ;

• Des événements externes tels des changements de phase de vol ou des alertes ;

• Des actions du pilote sur les différents organes de commande.

D'autre part, il existe un grand nombre d'images affichables. Ainsi, une table de configuration peut comporter plus de 10000 cellules unitaires à remplir.

La gestion de cette table pose plusieurs problèmes importants. Il est, bien entendu, très difficile d'en assurer une parfaite cohérence. Ainsi, deux événements similaires ne donnent pas nécessairement des configurations voisines, ce qui peut être très perturbant pour le pilote en particulier dans les phases de vol critiques. D'autre part, chaque changement de configuration, si mineur soit-il, va entraîner une refonte complète de la table de configuration. On estime que plusieurs milliers d'heures sont nécessaires pour la réalisation et la vérification d'une table de configuration pour un aéronef moderne.

La plupart des reconfigurations dépendent de règles logiques qui présentent l'avantage de permettre de synthétiser de façon cohérente une grand nombre de cas possibles qu'il serait fastidieux d'énumérer exhaustivement. Aussi, le principe de l'invention consiste à remplacer la réalisation de la table de configuration très lourde à créer et à entretenir par un procédé qui, à partir de ces règles logiques, génère de façon automatique la reconfiguration souhaitée.

Dans la suite de la description, certains mots ont un sens précis lié au contexte de l'invention. Leur définition apparaît au fur et à mesure du texte. Ces mots sont les suivants : place - jeton - événement - propriété - garde - conclusion - nœud. Les opérateurs logiques sont placés entre guillemets.

Plus précisément, l'invention a pour objet un procédé de configuration ou de reconfiguration d'une pluralité d'affichages appelés formats sur un ensemble de dispositifs de visualisation appelés visus, la reconfiguration d'une configuration initiale étant induite par une cause appelée événement pour aboutir à une configuration finale, caractérisé en ce que chaque configuration est obtenue essentiellement au moyen d'un langage logique de reconfiguration et d'un algorithme d'interprétation, ledit langage logique comprenant :

• Un domaine de reconfiguration : ensemble d'éléments comprenant principalement : o des places modélisant principalement les visus ; o des jetons modélisant principalement les formats ; o les événements ; o les fonctions logiques qui unissent les places, les jetons et les événements ;

• Des propriétés, ensemble de règles définissant les configurations acceptables ;

• Des règles de transition, ensemble de règles définissant les reconfiguratîons acceptables ;

• Des préférences définissant un ordre de calcul et des formats prioritaires sur les visus ; et le dit algorithme d'interprétation permettant de transformer chaque règle de transition en une liste de reconfigurations élémentaires. Avantageusement, les propriétés sont définies par des formules logiques construites à partir des éléments du domaine de reconfiguration, de comparateurs et d'opérateurs booléens.

Avantageusement, les règles de transition sont composées de trois éléments : « Un événement ;

• Une garde, formule logique qui définit l'ensemble des configurations initiales possibles avant l'événement ;

• Une conclusion, formule logique qui définit l'ensemble des configurations finales possibles après l'événement. Avantageusement, les règles de transition comportent des variables, une variable regroupant un ensemble de places ou de jetons, certaines règles de transition sont dites impératives, c'est-à-dire qu'elles doivent s'exécuter sans conditions et certaines règles de transition sont dites optionnelles, c'est-à-dire qu'elles doivent s'exécuter à la condition de ne violer aucune propriété.

Avantageusement, les préférences définissent :

• L'ordre de calcul des places ;

• L'ordre de préférence des jetons sur les places. Avantageusement, l'algorithme d'interprétation comprend une première étape de mise en forme appelée expansion dans laquelle :

• Les formules logiques des propriétés sont transformées en clauses disjonctives, suite d'égalités ou d'inégalités entre les éléments du domaine de reconfiguration séparées par les opérateurs logiques « ou » ; • Les gardes et les conclusions des règles de transition sont transformées en clauses conjonctives, suite d'égalités ou d'inégalités entre les éléments du domaine de reconfiguration séparées par les opérateurs logiques « et », un couple composé d'une garde et d'une conclusion sous la forme de deux clauses conjonctives étant appelé noeud initial, les

différents nœuds initiaux étant stockés dans une liste appelée liste initiale ;

• Les variables sont remplacées par leurs valeurs. Avantageusement, l'algorithme d'interprétation comprend une seconde étape d'interprétation des noeuds initiaux en nœuds finaux, ladite seconde étape comportant les sous-étapes suivantes :

• Création d'une seconde liste ce nœuds à partir de la liste initiale, les nœuds de cette seconde liste vérifiant la propriété suivante : si la garde du nœud vérifie toutes les propriétés du système, alors la conclusion du nœud vérifie toutes les propriétés du système ;

• Création d'une troisième liste ce nœuds à partir de la seconde liste, la conclusion des nœuds de cette troisième liste ne possédant plus d'inégalités ; • Création d'une liste finale à partir de la troisième liste, les gardes des nœuds de cette liste finale étant exclusives.

L'invention sera mieux comprise et d'autres avantages apparaîtront à la lecture de la description qui va suivre donnée à titre non limitatif et grâce aux figures annexées parmi lesquelles :

• La figure 1 représente une planche de bord comportant 8 visus ;

• La figure 2 représente le diagramme du procédé de configuration selon l'invention.

Le procédé selon l'invention est schématisé en figure 2. Il comprend deux grandes étapes principales. Dans une première étape, on définit un langage logique de reconfiguration. Dans une seconde étape, on établit les configurations élémentaires au moyen d'un algorithme d'interprétation de ce langage logique. Aussi, la description qui suit comprend également deux grandes parties qui sont :

• Le langage logique de reconfiguration ;

• L'algorithme d'interprétation.

Une troisième partie est consacrée à la simulation, à la génération et à la vérification des reeonfïgurations issues de l'algorithme d'interprétation.

Dans ce qui suit, tous les exemples pris concernent la reconfiguration de formats sur un ensemble de visualisations de planche de bord. On facilite ainsi la clarté du texte. Bien entendu, l'invention peut s'étendre à d'autres applications dans d'autres domaines techniques ou industriels en respectant les mêmes principes d'élaboration du langage logique et de l'algorithme d'interprétation.

LE LANGAGE LOGIQUE DE RECONFIGURATION

Le langage logique comprend essentiellement :

• Un domaine de reconfiguration, ensemble d'éléments comprenant principalement o des places modélisant principalement les visus ; o des jetons modélisant principalement les formats ; o les événements ; o les fonctions logiques qui unissent les places, les jetons et les événements ;

• Des propriétés, ensemble de règles définissant les configurations acceptables ;

• Des règles de transition, ensemble de règles définissant les reconfigurations acceptables ;

• Des préférences définissant un ordre de calcul et des formats prioritaires sur les visus.

Ce langage permet de décrire le domaine, les propriétés, les règles de transitions et les préférences de façon synthétique. Il possède une syntaxe formelle proche d'un langage mathématique.

Le domaine des reconfiguration Le domaine permet de définir les éléments manipulés par le langage, principalement, les visus, les formats et les événements. Les reconfigurations peuvent mettre aussi en jeu d'autres éléments : des modes, des mémorisations de format permettant d'afficher temporairement un format puis de retourner au format initial,...

Le domaine est constitué :

• d'un ensemble de places qui modélisent, par exemple, les visus, les modes,,..

• d'un ensemble de jetons qui modélisent, par exemple, les formats, les valeurs d'un mode,...

• d'un ensemble d'événements, chaque événement correspondant à une requête d'affichage de format, une panne de visu

• d'un ensemble de fonctions logiques et de relations du type : « tel format est plus prioritaire que tel autre »

A chaque instant, une place doit posséder un unique jeton.

Les propriétés Les propriétés permettent de définir les configurations acceptables. Elles sont définies par des formules logiques construites à partir des éléments du domaine, de comparateurs et d'opérateurs booléens du type « et », « non », « ou », « implique »,...

On peut remplacer les places et les jetons par des fonctions dans les formules logiques et ceci de manière récursive.

Les formules logiques sont bâties à partir de formules logiques élémentaires et d'opérateurs booléens.

Il est aussi possible d'utiliser des variables dans les formules logiques. Elles peuvent remplacer n'importe quelle place ou jeton dans une formule. On précise cependant au début de la formule, l'ensemble des valeurs que peut prendre cette variable.

Les règles de transition : gardes et conclusions

Les règles de transition définissent les reconfigurations acceptables, c'est à dire, les évolutions possibles d'une configuration initiale à une configuration finale lors de la réception d'un événement. Ainsi, une règle de transition est composée de trois éléments :

• L'événement qui déclenche la reconfiguration ;

• Une garde, formule logique qui définit l'ensemble des

configurations initiales sur lesquelles s'applique Ia règle de transition,

• Une conclusion, formule logique qui définit l'ensemble des configurations finales possibles suite à la reconfiguration,

II existe deux types de règles de transition :

• Les règles de transition impératives : ces règles de transitions doivent être exécutées dans toutes les conditions. Par exemple, une panne de visu est une règle impérative : " si une visu reçoit un événement de panne, alors elle doit impérativement s'éteindre ".

• Les règles de transition optionnelle : ces règles sont satisfaites uniquement si la configuration finale ne viole aucune propriété du système. Par exemple, si une propriété du système est que tel format doit être unique dans le cockpit, alors la requête d'affichage de ce format ne sera satisfaite que s'il n'existe aucun autre format identique déjà affiché dans le cockpit.

Certaines règles de transitions sont implicites. C'est le cas des règles sur l'allumage et la panne d'une visu qui doivent être ajoutées automatiquement lors de la définition du domaine.

Il est également possible d'utiliser des variables dans les formules logiques définissant la garde et la conclusion de la règle. Cependant, il est préférable de déclarer les variables dans l'entête de la transition plutôt que dans chaque formule, ainsi on peut utiliser des variables communes à la garde et à la conclusion.

Les préférences

Les propriétés et les règles de transitions limitent les reconfigurations possibles mais ne suffisent pas toujours à déterminer exactement le comportement de ces reconfigurations. Les préférences comblent les lacunes de la spécification.

Les préférences sont de deux types :

• L'ordre de calcul des places ; • L'ordre de préférence des jetons sur les places.

L'ordre de calcul des places est un ordre total sur les places du domaine. En cas d'imprécision sur une reconfiguration, on détermine en premier le jeton de Ia première place dans l'ordre de calcul, puis Ia seconde et ainsi de suite jusqu'à Ia dernière place. Pour chaque place, on ordonne les jetons par ordre de préférence. En cas d'imprécision sur le prochain jeton de la place lors d'un reconfiguration, on choisit le premier jeton dans l'ordre de préférence ne contredisant aucune propriété du système.

Les reconfigurations élémentaires

Les reconfigurations élémentaires permettent de calculer les reconfigurations du système. Pour une configuration donnée et un événement reçu, les reconfigurations élémentaires déterminent exactement la reconfiguration à effectuer. Un reconfiguration élémentaire est une règle de transition impérative. La garde permet de définir si la reconfiguration élémentaire s'applique. Si la configuration actuelle vérifie la garde et si l'événement est reçu, alors la reconfiguration élémentaire s'applique. Dans ce cas, on calcule la nouvelle configuration en interprétant les égalités de la conclusion comme des affectations.

L'ALGORITHME D'INTERPRETATION

Le langage logique de reconfiguration, à lui seul, n'est pas opératoire. La fonction de l'algorithme d'interprétation est de prendre une règle de transition et de la transformer en une liste de reconfigurations élémentaires directement applicables.

Pour cela, l'algorithme d'interprétation injecte les propriétés du système et les préférences dans les règles de transitions en utilisant un algorithme de résolution semblable à celui du langage de programmation Prolog.

Expansion et génération des clauses

L'algorithme nécessite au préalable une étape de mise en forme, appelée expansion, des transitions et des propriétés.

Le but de Ia phase d'expansion est de mettre sous une forme plus simple les formules présentes dans les gardes et les conclusions des transitions et dans les propriétés. Les formules dans les propriétés et les transitions sont transformées en clauses. Les clauses sont des suites d'égalités ou d'inégalités séparées soit :

• par des « ou », on parle alors de clauses disjonctives ;

• par des « et », on parle alors de clauses conjonctives .

Les propriétés sont transformées en clauses disjonctives, c'est à dire en une suite de formules élémentaires séparées par des opérateurs booléens « ou ». Pour cela, on utilise les équivalences élémentaires des connecteurs booléens. Toutes les formules ne se réduisent pas nécessairement à une unique clause disjonctive mais une formule peut toujours être mise sous la forme d'une suite de clauses disjonctives séparées par des opérateurs booléens « et ». L'algorithme de transformation en clauses disjonctives prend en entrée une formule et renvoie la clause calculée. Cet algorithme s'arrête lorsqu'il ne peut plus transformer la formule en une unique clause disjonctive.

Les formules de gardes et de conclusions sont transformées en clauses conjonctives, c'est à dire en une suite de formules élémentaires séparées par des « et » . Pour cela, on utilise les mêmes équivalences élémentaires que pour les clauses disjonctives. Comme pour les clauses disjonctives, toutes les formules ne se réduisent pas nécessairement à une unique clause conjonctive mais une formule peut toujours être mise sous la forme d'une suite de clauses disjonctives séparées par des opérateurs booléens « ou ».

On doit également substituer dans les transitions ou les propriétés, les variables par toutes les valeurs possibles. Ainsi, pour chaque ensemble de valeurs possibles, on obtient une transition ou une propriété sans variables.

Suite à la phase d'expansion, toutes les propriétés du système sont sous la forme de clauses disjonctives sans variables et toutes les transitions du système ont leurs gardes et leurs conclusions sous la forme de clauses conjonctives sans variables.

L'algorithme d'interprétation prend alors en entrée une transition résultante de l'expansion et donne en sortie une suite de reconfigurations élémentaires.

Nœuds et listes

L'algorithme d'interprétation manipule des nœuds. Un nœud est un couple composé d'une garde et d'une conclusion sous la forme de deux clauses conjonctives séparées par des «et ».

L'algorithme part d'un nœud initial provenant d'une transition et va affiner la garde et la conclusion de ce nœud en utilisant les propriétés et les préférences du système. Ce procédé va produire un ensemble de nœuds qui va croître au fur et à mesure de l'affinage.

Concrètement, ces nœuds sont stockés dans une suite de listes. Chaque liste garantit des propriétés de plus en plus strictes sur les nœuds qu'elle contient. L'affinage consiste à faire passer les nœuds vers les listes aux propriétés les plus strictes. Les listes sont les suivantes :

• Une liste Listln pour les nœuds d'entrée ;

• Une liste ListMediumi dont les nœuds vérifient la propriété suivante : « si la garde vérifie toutes les propriétés du système, alors la conclusion vérifie toutes les propriétés du système» ;

• Une liste ListMedium2 dont les nœuds vérifient la propriété : « La conclusion ne possède plus d'inégalités» ;

• Une liste ListOut dont les nœuds vérifient les propriétés de ListMedium2 et la propriété supplémentaire: « Les gardes de tous les nœuds sont exclusives ».

La méthode opératoire de l'algorithme est de conduire les nœuds de la liste Listln vers la liste ListOut en passant par les listes ListMedium. Pour réaliser cette opération, l'algorithme utilise plusieurs procédures successives.

Les nœuds sont composés d'un couple comprenant une garde et une conclusion qui sont des clauses conjonctives séparées par des « et ». Le sens d'une clause et plus généralement d'une formule est donné par l'ensemble des configurations qui la vérifie. Lorsque plusieurs formules s'écrivent de manière différente et ont le même sens, elles sont dites équivalentes. Un ensemble de formules équivalentes entre elles est appelé une classe d'équivalence. Pour chaque classe d'équivalence, on choisit une forme normale qui va représenter toutes les formules de la classe et que l'on notera, dans la suite du texte entre crochets.

L'algorithme doit pouvoir travailler avec les formes normales comme avec des formules logiques .

En conclusion, les nœuds manipulés par l'algorithme sont des couples comprenant une [garde] et une [conclusion] où ;

• [garde] est la forme normale de la garde ;

• [conclusion] est la forme normale de la conclusion.

De plus, l'algorithme va associer à chacune des gardes et des conclusions, un ensemble de propriétés. Ces propriétés sont les propriétés restant à valider pour la garde ou la conclusion.

Pour la conclusion, le but est de faire décroître cet ensemble vers l'ensemble vide. Dans ce cas, la conclusion vérifie toutes les propriétés du système puisqu'il ne reste plus aucune propriété à valider. Pour la garde, on précise ainsi la garde dans la mesure où la configuration de départ vérifie toutes les propriétés du système. On optimise ainsi les résultats obtenus.

Initialisation des noeuds L'algorithme d'interprétation comporte une première phase d'initialisation. L'initialisation prend une transition résultat de l'expansion, créé un nœud avec la garde et la conclusion de la transition et la met dans la liste Listln.

A l'initialisation, on associe à la garde et la conclusion l'ensemble des propriétés restant à valider. Comme aucune opération n'a été faite,

l'ensemble de ces propriétés est l'ensemble de toutes les propriétés du système de reconfiguraiîon.

Injection des propriétés L'algorithme d'interprétation comporte une seconde phase dite d'injection des propriétés.

Le but de cette étape est de fabriquer des nœuds dont les conclusions vont vérifier les propriétés du système. Certaines propriétés sont vérifiées d'emblée par la conclusion. Pour toutes les autres propriétés, il faut affiner les conclusions selon une méthode basée sur la résolution logique classique identique à celle du langage Prolog.

On définit une fonction résolution qui, pour une propriété et une conclusion, élimine dans la propriété toutes les (in)égalités incompatibles avec la conclusion d'un nœud.

Ii existe cependant des cas où il reste plus d'une (in)égalité dans la propriété après élimination par l'algorithme de résolution.

Résolution des inégalités. L'algorithme d'interprétation comporte une troisième phase dite de résolution des inégalités. Le but de cette étape est de remplacer toutes les inégalités par des égalités dans les conclusions.

De manière plus précise, on cherche à éliminer les inégalités qui vont entraîner une recoπfiguration, c'est à dire les inégalités qui sont dans la conclusion mais pas dans la garde.

Distinction des gardes

L'algorithme d'interprétation comporte une quatrième phase dite de distinction des gardes. On veut empêcher dans cette étape que, dans une configuration donnée, on puisse avoir le choix entre deux reconfigurations issues d'une même transition et menant à des configurations finales différentes, créant ainsi un indéterminisme.

Formellement, le but de cette étape est d'obtenir des nœuds dont les gardes sont deux à deux exclusives. On procède par dichotomie. On

choisit un critère de dichotomie, on divise l'ensemble des gardes en deux sous-ensembles :

• l'ensemble des gardes qui vérifie le critère ;

• l'ensemble des gardes qui vérifie son contraire. On itère sur les deux sous-ensembles obtenus.

Il est intéressant de trouver à chaque étape le critère qui sépare l'ensemble des gardes en deux sous-ensembles de taille à peu près égales. Dans Pimpiémentation, on calcule le nombre de chaque égalité dans les gardes et on choisit ensuite celui qui minimise le terme T avec : T =((N/2 -Ni) 2 -(N/2 -N 2 ) 2 )

Où N est le nombre total de nœuds, Ni est le nombre de nœuds vérifiant la garde et N 2 est le nombre de nœuds ne vérifiant pas la garde.

L'algorithme s'arrête lorsqu'on ne trouve plus de critères capables de scinder l'ensemble en deux. A ce stade, cela signifie que tous les nœuds ont une garde identique avec des conclusions différentes.

On peut choisir une conclusion parmi les différentes conclusions.

Cependant, certaines configurations vérifiant la garde peuvent avoir une reconfiguration ou une conclusion préférables. Les critères de préférence dépendent essentiellement du nombre de visus à reconfigurer que l'on souhaite minimiser et de l'ordre de préférence des formats.

Dans ce cas, on continue à scinder l'ensemble de gardes non pas pour distinguer les gardes mais pour obtenir des gardes dont les configurations ont une seule conclusion préférable.

Mise en forme

La mise en forme consiste à transformer tous les nœuds de la liste ListOut en reconfigurations élémentaires :

• l'événement est celui de Ia transition en entrée de l'algorithme • la garde et la conclusion sont choisies parmi celles appartenant à la classe d'équivalence représenté par la forme normale

A l'issue de la mise en forme, on obtient un ensemble de reconfigurations élémentaires pour chaque transition obtenue suite à

l'expansion. Ces reconfigurations élémentaires possèdent les propriétés suivantes :

• Les reconfigurations élémentaires conservent les propriétés du système. Si C est une configuration initiale vérifiant toutes les propriétés du système et si C est une configuration finale obtenue suite à une reconfiguration élémentaire, alors C vérifie toutes les propriétés du système.

• Les reconflgurations élémentaires ont leur garde exclusive deux à deux. On ne peut pas appliquer deux reconfigurations issues d'une même transition issue de l'expansion.

• Les reconfigurations élémentaires sont conformes aux transitions. E étant un événement, si (Ce 1 C) est une reconfiguration obtenue par application d'une reconfiguration élémentaire, alors elle est une reconfiguration acceptable pour la règle de transition dont est issue la reconfiguration élémentaire.

Cependant, l'algorithme d'interprétation a un certain nombre de limites

• L'algorithme d'interprétation garantit uniquement que les gardes sont disjointes deux à deux pour une transition issue de l'expansion. Il ne garantit pas que les gardes soient disjointes pour des reconfigurations élémentaires issues de deux transitions différentes ou bien d'une transition avec des valeurs de variables différentes ;

• L'algorithme d'interprétation ne garantit pas la complétude des règles de transition. Dans certains cas, on ne peut pas effectuer la reconfiguration car la configuration finale ne vérifie pas les propriétés du système. Pour une transition de type impérative, il faut vérifier que, pour toute configuration, si cette règle de transition s'applique sur la configuration, alors il existe une reconfiguration élémentaire issue de la règle de transition qui s'applique aussi sur Ia configuration.

Aussi, des vérifications doivent être faites.

VERIFICATIONS, GENERATION DES RECONFIGURATIONS ET SIMULATION,

Vérifications

Les vérifications permettent de vérifier que l'ensemble des règles de reconfigurations élémentaires est un système ayant les caractéristiques suivantes :

• II est opérationnel. Pour une configuration donnée et un événement, il doit permettre de calculer la reconfiguration à effectuer ; » 11 est déterministe. Pour une configuration donnée et un événement, il n'existe pas plusieurs reconfigurations possibles.

• II est complet par rapport aux règles de transitions . Pour une transition de type impérative, il vérifie que certaines reconfigurations ne sont pas perdues en utilisant les reconfigurations élémentaires. Plus formellement, pour toute configuration, si une règle de transition s'applique sur la configuration, alors il existe une reconfiguration élémentaire issue de la règle de transition qui s'applique aussi sur la configuration. • II préserve les propriétés. Les reconfigurations élémentaires ne peuvent pas produire de configuration ne vérifiant pas les propriétés du système.

Ces vérifications portent sur les reconfigurations élémentaires. D'autres vérifications doivent être aussi menées sur le langage logique. Elles concernent essentiellement la consistance des propriétés, l'ensemble des propriétés du système ne devant pas être contradictoire. Plus simplement, il doit exister au moins une configuration vérifiant toutes les propriétés du système.

Le système est automatiquement opérationnel par construction.

Concernant le déterminisme du système, il faut vérifier qu'il n'existe pas plusieurs reconfigurations possibles pour une configuration donnée. Formellement, il suffit de s'assurer que les gardes des reconfigurations élémentaires pour un événement donné sont deux à deux

disjointes. On sait que l'algorithme d'interprétation garantit que deux reconfigurations élémentaires issues d'une transition où toutes les variables ont été évaluées ont des gardes disjointes. Donc, des erreurs sont présentes si : • Deux règles de transitions existent avec des gardes non disjointes

• Une règle de transition existe avec des variables qui donnent des gardes non disjointes pour deux évaluations possibles des variables. Dans les deux cas, il faut réécrire les règles de transitions pour corriger ces erreurs.

Pour que la complétude soit vérifiée, il faut qu'une transition impérative et l'ensemble des reconfigurations élémentaires issues de ladite transition s'applique sur le même ensemble de configurations.

La préservation des propriétés est couverte par l'algorithme d'interprétation de la manière suivante. Si la configuration avant reconfiguration est acceptable, elle vérifie alors toutes les propriétés du système, alors la configuration après reconfiguration est aussi acceptable, elle vérifie également toutes les propriétés du système. Il suffit de vérifier que la ou les configurations à l'initialisation du système vérifient toutes les propriétés du système. Du même coup, on garantit la consistance des propriétés puisqu'il existe au moins une configuration, la configuration initiale qui vérifie toutes les propriétés du système.

II faut également vérifier qu'une configuration donnée est acceptable, c'est à dire qu'elle vérifie toutes les propriétés du système.

Génération de code La simulation et la génération de code s'appuient sur un processus de base exécuté en boucle qui, étant donnée une configuration initiale et un événement reçu, calcule la prochaine configuration. On peut le

mettre sous Ia forme d'une fonction qui calcule la prochaine configuration à partir d'une configuration et d'un événement.

Le calcul de la prochaine reconfiguration recherche la reconfiguration élémentaire dont la garde est vérifiée par la configuration initiale, puis applique la conclusion de la reconfiguration élémentaire sur la configuration initiale pour obtenir la configuration finale.

La génération de code passe par un grand nombre de solutions possibles. Par exemple, on peut écrire une fonction de reconfiguration générique une fois pour toutes. Cette fonction a pour rôle d'élire la reconfiguration élémentaire et de l'appliquer. Pour cela, elle utilise les reconfigurations élémentaires générées soient sous la forme de tableaux ou de données élémentaires, soit sous la forme de codes.

Simulation et traçabilité La simulation permet de valider la spécification d'entrée. Il est donc important pour chaque reconfiguration de déterminer les propriétés, les préférences et les règles de transitions qui ont servi à calculer la reconfiguration. A cette fin, on utilise une fonction de traçabilité qui associe à chaque reconfiguration élémentaire, la règle de transition, les propriétés et les préférences qui ont permis son calcul.