Cycle de développement proposé

La gure 5.2 représente le cycle de vie classique d'un logiciel dédié à la supervision qui, pour le rendre opérationnel, il faut passer par le chemin descendant pour sa formulation jusqu'à son implémentation et pour le valider, le tester et le rendre exploitable; il faut passer par les étapes ascendantes.

Analyse du problème

Spécification formelle Orientée SMA avec RdP

pour l’aspect dynamqie

Modèle global Communication, coordination et pilotage Tests unitaires Tests fonctionnels et Simulation du modèle Tests d’intégration Exploitation des Résultats simulés Détection de nouvelles Situations Apprentissage (vision IMS) Validation Développement Informatique, Choix et des outils de programmation

et d’Intégration

Tests de performances

(a)

(b)

Fig. 5.2  Notre vision de cycle de développement orienté SMA [8] 1. La spécication des besoins de la e-maintenance est caractérisée par :

 L'aspect hétérogénéité des sites de production,

 la nature de la distribution (complètement distribué, hiérarchique distribué),  le type d'interaction engendrant la coopération ou non.

Cette spécication se concrétise généralement en deux grandes étapes :  informelle, obéissant à un cahier des charges,

 formelle,équivalente sémantiquement à la première, mais qui tient compte des exigences des règles d'écriture du langage de spécication, tout en faisant abstraction à l'implémentation pour le moment.

Cette étape, même si elle se situe avant la phase conception, elle doit prendre en considération la structure du modèle dans lequel sera conçu ce e-système.

2. La modélisation générale de la e-maintenance, l'axe central du cycle de vie, qui structure au mieux l'architecture du e-système avec bien évidemment étude des diérentes interactions et communication entre les éléments du e-système, pour cela, il faut :

 Etude des diérentes modélisations associés aux sites, et voir ce que peut ap- porter chacune des modélisations comme contribution dans le la modélisation du système global. Faire recours, par exemple, à la modélisation par réseau de Petri (RdP) pour les cas dynamiques.

 Opter pour un type de modélisation en faisant toute l'étude portant sur :  L'architecture du e-système (hiérarchique, niveaux de hiérarchie, etc.).  Etude des composants du e-système.

 Comment représenter chaque composant?  L'interaction entre ces composants.  La coopération entre les composants.

 Le comportement des composants et du e-système pour l'accomplissement des buts visés.

 etc.

3. l'analyse et l'évaluation des performances : La vérication (ou peut être certica- tion) de tout logiciel utilisé pour la commande est une tâche essentielle. Sa concep- tion et son implémentation est certes d'ordre informatique, mais la façon dont il faut spécier les fonctions réalisées par ce logiciel dépend fortement de l'application et cela entraînent des spécicités. Dans le cycle de vie classique en " V ", chaque étape (analyse, conception architecturale, etc.) comprend également la dénition des procédures de test (e-système, sous-systèmes, unités, etc.) et de vérication. Deux approches majeures sont généralement utilisées dans cette étape de la super- vision des e-systèmes de Production pour analyser et évaluer le logiciel produit :

(a) l'une relevant de la simulation, plus proche du système réel permettant d'ex- plorer les régimes transitoires et permanents mais demandant certaines pré- cautions pour l'interprétation et la validation des résultats,

(b) la seconde, analytique, nécessitant des simplications physiques plus impor- tantes, donnant des résultats exacts ou plus approchés au détriment d'une plus grande complexité et se limitant aux régimes permanents.

Comme notre tâche dans le cycle cité se limite à la phase spécication formelle et modélisation générale, nous serons contraints à valider notre modèle par la première méthode, c'est-à-dire une simulation de scénarios pour des études de cas.

4. la maintenance au cours du temps. Cette tâche sera aisée si la conception du système est modulaire et ouvert et répond aux critères ecaces du génie logiciel. La réalisation du logiciel peut se faire :

(a) Soit en diéré (o-line) telle que la conception formelle du logiciel de com- mande, maintenances préventives, etc.

L'adaptation de l'approche SMA à la e-maintenance n'est pas chose évidente, puis- qu'il s'agit :

(a) de comprendre et cerner la politique et les techniques de maintenance associée à chaque site pour pouvoir la modéliser.

(b) partir d'une étude de cas qui va comprendre :  étude du cahier des charges d'un cas posé,

 spécier informellement les besoins associés au cas posé,  spécier formellement ces besoins en :

 Se xant comme architecture générale une structuration e-système de production, c'est-à-dire des agents distribués nommés, avec lesquels on peut communiquer (accointances).

 Concevoir un métalangage de communication entre agents en fonction de cette architecture :

 Syntaxiquement, basé communication (envoi et réception de messages entre agents basés sur la négociation et la coopération),

 Sémantiquement basée modèle d'exécution parallèle.

 Simuler ce métalangage sur le cas posé, en faisant appel à des logiciels qu'on intègre dans le processus de réalisation (KADS, Ilog Solver, etc.). En productique, on suppose que le système d'exploitation et les réseaux locaux sont corrects, ils ne sont pas au centre des préoccupations.

Le producticien développe des modèles qu'il implémente pour surveiller le procédé et extraire les informations qu'il trouve utiles. Il se focalise essentiellement sur la partie du système informatique correspondant à l'application, c'est-à-dire mettant en oeuvre les fonctions à remplir par le système de commande et de surveillance.

Le choix de la plate-forme sur lequel l'application doit être exécutée, ou du moins simulée et validée, est fondamental. Le fait que l'architecture du e-système est distribuée, deux solutions se présentent devant nous dans notre cas:

1. Implémentation du système sur une architecture parallèle. 2. Simuler l'exécution sur :

 Un système d'exploitation multitâche à part entière (genre Linux), où chaque agent associé à sous système sera associé à un processus (au sens informatique du terme) durant son activation (passage de l'objet vers l'agent).

 Windows-xx par multithreading où l'activation de chaque agent est simulé par un thread,

 Une plate-forme sur un réseau local ou dédié, où chaque agent est associé à un poste.

5.4 Modélisation de la e-maintenance