Évolution requise

Une évolution requise est une évolution d'une chaîne fonctionnelle de l'environnement, avec

ou sans eet sur des produits, sans laquelle il peut être impossible de répondre à la demande.

Les évolutions requises modélisent les informations indispensables qu'un module

coordina-tion doit connaître de son environnement (da Silveira, 2003). En eet, de par les interactions

entre le système contrôlé et son environnement dans les espaces partagés (cf. Figure 3.3), la

68 Chapitre 4. Caractéristiques du Modèle

réalisation de services oerts par les chaînes fonctionnelles contrôlées est contrainte par l'état de

l'environnement et des produits sur lesquels il agit.

La réalisation d'une évolution requise dépend de l'environnement et de sa propre stratégie.

Le niveau coordination considéré ne pilotant pas son environnement, il ne peut pas déclencher

une évolution requise. Seules les informations qui lui seront fournies par l'environnement

permettront dans certains cas de connaître le début et la n d'une évolution requise. C'est la

situation, par exemple, d'attente de l'arrivée d'un produit dans un stock d'entrée.

Le choix de l'outil de modélisation qui est conditionné par les informations à modéliser et

leur structuration dépend aussi en partie des propriétés du modèle présentées dans la section

suivante.

4 Propriétés du modèle

Le modèle déni par l'ensemble des informations structurées en quatre catégories

d'opé-rations possède les propriétés suivantes : parallélisme et concurrence entre les opéd'opé-rations,

synchronisation, et enn déterminisme et indéterminisme. Si les trois premières sont celles d'une

loi de commande, l'indéterminisme est en revanche spécique au modèle. Nous traiterons dans

cette section le déterminisme et l'indéterminisme qui sont liés.

Le déterminisme concerne les eets sur l'état des chaînes fonctionnelles et des produits

des opérations d'action, des évolutions induites et requises. En eet, en l'absence d'aléa, les

évolutions des chaînes fonctionnelles et du ux de produits résultantes d'une des trois catégories

d'opérations citées précédemment sont déterministes au sens où, depuis un état, l'opération

conduit dans un seul et unique état. Du point de vue des chaînes fonctionnelles, ce déterminisme

traduit également la relation de cause à eet entre les requêtes émises par le système de

commande et les évolutions résultantes des chaînes fonctionnelles en l'absence d'aléa.

L'indéterminisme résulte quant à lui d'une part des eets des opérations d'information, et

d'autre part des combinaisons possibles entre les opérations an d'atteindre un état donné.

Basée sur un service oert par une chaîne d'acquisition, une opération d'information renseigne

le module de coordination de l'état du ux de produits. Le recours à une opération d'information

s'avère nécessaire quand il existe une incertitude sur l'état d'entrée du ux de produits. Aussi,

l'état atteint à la n de l'opération d'information sera fonction des données accompagnant le

compte rendu de n de l'opération. Il existe ainsi un indéterminisme sur l'état atteint suite à

l'exécution d'une opération d'information.

En sus de cet indéterminisme, les opérations à exécuter et leur enchaînement an d'atteindre

un état souhaité est indéterministe de par la exibilité physique du système de production.

Sans cet indéterminisme, il n'y aurait plus de problème d'optimisation puisque la solution serait

unique.

Les informations à modéliser, leur structuration et les propriétés du modèle étant maintenant

dénies, il nous reste à choisir un outil de représentation. Ainsi, la section suivante vise à établir

l'outil le mieux adapté.

5. Outil de Modélisation 69

5 Outil de Modélisation

En premier lieu, l'outil de modélisation doit permettre la représentation des informations

avec la structuration proposée et les propriétés qui en découlent. Mais la seule considération

de ces quatre aspects n'est pas susante an de déterminer l'outil de modélisation le mieux

adapté. Ainsi en plus de ces aspects, nous considérerons, par ordre d'importance, les trois critères

suivants :

1. guider au maximum l'expert chargé de réaliser le modèle (aspect graphique ou non,

struc-turation du modèle, etc) ;

2. extraire facilement les diérentes données dont l'algorithme de synthèse aura besoin ;

3. faciliter la validation du modèle.

La diculté majeure liée à la modélisation est l'obtention de l'ensemble des informations

que seul l'expert est en mesure d'apporter, d'où l'importance de ce critère. Ainsi, l'outil de

modélisation doit être une aide an de collecter, de la façon la plus intuitive et naturelle possible

pour l'expert, l'ensemble des informations. En résumé, l'outil doit faciliter l'assimilation par

l'expert des capacités de la partie opérative. De plus, l'outil se doit de ne pas introduire de

dicultés supplémentaires liées à son utilisation et à son formalisme.

Pour ces raisons, nous avons choisi une modélisation par opération. Cet outil de modélisation,

comme nous le verrons au cours de cette partie, ore l'avantage de ne pas nécessiter une vision

globale du système contrôlé, mais impose à l'expert de se focaliser sur une chaîne fonctionnelle

et son environnement.

Tel que nous le verrons dans la quatrième partie consacrée à une étude de cas, le recours à un

outil de type automate ou réseaux de Petri engendre, dans ce cas, une complexité telle que tout

l'intérêt de l'aspect graphique de ces outils est perdu. En eet, l'étude que nous avons menée sur

l'utilisation de l'outil réseaux de Petri (Deschamps,2004) et qui ne sera pas reprise ici pour des

raisons de concision a conduit à ces conclusions.

Néanmoins, le choix de l'outil que nous avons fait n'interdit pas à des ns de validation du

modèle une représentation basée sur un autre outil tel que les réseaux de Petri. Il s'agit alors de

transformer le modèle comme nous l'avons proposé dans (Deschamps et al.,2004).

6 Conclusion

Dans ce chapitre, nous nous sommes attachés à présenter les caractéristiques fondamentales

que le modèle doit posséder. La démarche de recherche de ces caractéristiques a été largement

orientée par le point de vue eet miroir (cf. Figure 3.1 page 52) que nous avons des modules

de coordination, des chaînes fonctionnelles et de leur rôle sur le ux de produit. Aussi, nous

avons proposé un balayage systématique de toutes les informations à capitaliser dans le

modèle, en partant des grandeurs de commande oertes aux modules de coordination jusqu'aux

informations quantitatives liées aux évolutions des chaînes fonctionnelles, des produits et de

l'environnement, qui permettra à terme d'évaluer les performances de la solution proposée. Au

delà de la mise en exergue des sept types d'informations à modéliser, nous avons également

proposé une structuration du modèle. Celle-ci, argumentée sur la base du principe de causes

à eets existant entre les grandeurs de commande et les évolutions s'articule autour de quatre

70 Chapitre 4. Caractéristiques du Modèle

catégories d'opérations : les opérations d'action, les opérations d'information, les évolutions

induites et enn les évolutions requises. Après avoir discuté des propriétés intrinsèques au

modèle, notamment sur le plan de son indéterminisme natif, nous avons terminé ce chapitre par

une spécication des besoins du formalisme requis pour représenter la structure complexe de

données proposée.

Les caractéristiques fondamentales du modèle étant désormais avancées, nous nous proposons

de présenter, dans le détail, le formalisme que nous avons développé.

Dans le document Synthèse de Lois de commande pour la configuration et la reconfiguration des systèmes industriels complexes (Page 68-72)