Communication et synchronisation des composants reconfigurables

Télécharger le fichier pdf d’un mémoire de fin d’études

Detection des besoins de recon guration

Un premier probleme concernant la recon guration dynamique des systemes de contr^ole industriel a base des composants est represent au niveau de la recon guration de ces composants localement, qui consiste a detecter d’une part les conditions imprevisibles du changement de l’environnement a l’execution de ces composants qui necessitent des recon gurations du composant, et d’autre part de s’assurer que le composant concern est dans un etat qui permet d’appliquer la recon guration demandee de facon s^ure et automatique sans perturber l’execution du systeme.
Par exemple : suite a une panne d’un capteur d’un systeme radar, il faut detecter les be-soins de recon guration comme le changement climatique ou l’augmentation de vitesse du vent a n de proposer des scenarios de recon gurations qui ne violent pas le fonctionnement du capteur. Puis la mise en oeuvre des mecanismes de recon guration.

Veri cation formelle du comportement

La recon guration est dediee essentiellement a la modi cation du comportement in-terne qui complique considerablement l’execution du systeme ou du composant et qui permet la perturbation de son fonctionnement qui touche essentiellement son architecture, sa structure et ses donnees. En e et, il est necessaire de suspendre certains algorithmes du systeme pour leur permettre de se recon gurer. Si ces algorithmes sont modi es par la recon guration, on ne peut les suspendre qu’une fois qu’ils ont fourni leurs resultats ; sans quoi il est probable que le comportement du systeme devient incoherent. Nous ap-pelons architecture exible, l’architecture qui supporte les actions de la recon guration.
Cette derniere permet de realiser la recon guration de facon s^ure et automatique. Nous devrons egalement nous interesser aux problemes que pose la veri cation du comportement apres chaque recon guration. Nous devrons egalement proposer une methode d’analyse et veri le comportement du systeme recon gurable, a n de veri er que les scenarios de recon gurations veri ent un certain nombre de proprietes.

Communication et synchronisation des composants recon gurables

Le troisieme probleme reside au niveau de la coordination et la communication entre les composants recon gurables. Au-dela de la mise en uvre pratique des recon gurations ables des composants, et comment garantir la coherence des recon gurations dans une architecture distribuee a base des composants recon gurable automatiquement, nous de-vons egalement proposer un protocole de coordination dans le cas ou les recon gurations sont synchrones a n de recon gurer globalement le systeme. Une matrice de coordination est proposee qui permet la gestion de la coordination et la synchronisation d’une facon s^ure a n de veri er certaines proprietes de s^uret de coherence, coordination correcte et ne viole pas l’aspect fonctionnel du systeme.

Securit des composants recon gurables

Un systeme recon gurable est ouvert a toutes formes d’attaques exterieures et des utilisations malveillantes dans le contexte d’un reseau ouvert se traduisant par une modi – cation ou dysfonctionnement illegale. Par exemple, un scenario de recon guration peut ^etre utilise pour attaquer le systeme ou un composant. Au-dela de la mise en oeuvre pratique d’une securisation able du systeme pour garantir un niveau tres elev de securite, nous devrons egalement proposer une methode pour securiser le systeme ou ses composants.
Ces di erents problemes seront fortement ra nes lorsque nous presenterons l’etude detaillee des besoins auquel nous allons repondre (Partie 2).

Speci cation du composant RA2DL

La premiere etape consiste a speci er les caracteristiques locales du nouveau compo-sant RA2DL. D’abord, nous regroupons les formes de recon guration en trois modes : architecturales, compositions (structures) et donnees. Ensuite, nous proposons une nou-velle architecture qui s’adapte aux trois formes de recon gurations, c’est une architecture exible repartie en quatre modules fondamentaux. Le premier module est dedi aux ev – nements d’entrees, le deuxieme est consacre aux algorithmes internes du composant, le troisieme est reserv pour les evenements de sorties et le quatrieme dedie pour les donnees du composant. En n, nous formalisons les comportements de RA2DL en tenant compte ces trois formes de recon gurations [AMKB15b] [AMKB15c].

Veri cation du composant RA2DL

La deuxieme etape concerne la veri cation des proprietes de s^urete, de vivacite, d’at-teignabilite, de securite, etc. de RA2DL, en utilisant le modele checker UPPAAL [Mer01] base sur les automates temporises pour la modelisation des composants et la logique TCTL (Timed Compotational Tree Logic) [ACD90] pour veri er les proprietes de comportement, de synchronisation et de la securit de RA2DL. [AMKB15a].

Conception du composant RA2DL

La troisieme etape consiste a representer l’ensemble des besoins fonctionnels et non fonctionnels de RA2DL au niveau de la conception. Il s’agit de creer une representation simpli ee par un modele et un meta-modele du composant RA2DL en utilisant le langage de modelisation uni e (UML) a n de montrer les vues statiques et dynamiques de RA2DL par un ensemble de diagrammes.

Securit du composant RA2DL

La quatrieme partie est consacree a la securisation du composant RA2DL. Nous pro-posons dans ce contexte une methode qui s’articule autour de la notion du P ool, qui est un conteneur represent par une super-classe qui vise a regrouper des composants RA2DL selon un facteur de similarite a n d’a ecter les di erentes politiques ou des mecanismes de securit selon le niveau de sensibilit de ces composants [AMKB16].

Flexibilit du composant RA2DL

La cinquieme etape est dediee aux mesures de la exibilit de RA2DL, qui est un facteur crucial qui permet de calculer les taux d’acceptation de scenarios de recon guration. Ce facteur est compare a un seuil f lexR donne par un expert. Pour mesurer la exibilit d’un tel composant RA2DL, nous proposons une approche intitulee F lex RA2DL qui s’appuie sur un algorithme AlgF lex dans le but de calculer cette exibilit .

Implementation du composant RA2DL

La sixieme etape est reservee a l’implementation du composant RA2DL, par la mise en uvre de l’ensemble de ses modules sur une carte Arduino et la realisation d’un ou-til complet intitule RA2DL T ool qui realise toutes ces fonctions de la speci cation a l’implementation nale. L’application de notre approche est testee sur trois etudes de cas concretes a n d’en valider les performances et montre l’applicabilite de notre approche dans le domaine de l’industrie.

Organisation du Manuscrit

Le manuscrit de these est organise en sept chapitres structures comme suit :
– Chapitre 2 : dresse un etat de l’art sur l’approche par composant (l’approche on-line et o -line) et l’ingenierie dirigee par les modeles IDM. Apres la de nition du systeme de contr^ole industriel, nous decrivons une etude detaillee du langage AADL et comment un composant de ce langage peut ^etre exploit pour appliquer la recon guration locale au niveau du composant. Nous exposons les methodes de recon gurations statiques et dynamiques existantes nous detalions dans ce cadre les methodes de la recon guration automatique des systemes temps-Reels embarques. Nous discutons aussi les limites des solutions existantes a n de synthetiser toutes ces approches.
– Chapitre 3 : comporte la premiere contribution de notre these representee par une approche qui analyse la recon guration d’un composant AADL et la transformation en un composant RA2DL. Cette approche vise a etudier les formes de recon gurations possibles s’appliquant au RA2DL a n de proposer une architecture exible. Nous proposons la formalisation du composant RA2DL avec ces comportement, la modelisation de RA2DL avec des automates temporises et le calcul du facteur de exibilit de RA2DL. Avant de conclure nous illustrons un exemple simple pour montre le passage d’un composant AADL a un composant RA2DL recon gurable.
– Chapitre 4 : presente des extensions possibles a un composant RA2DL pour faci-liter son execution dans une architecture distribuee pour garantir une coherence avec des recon gurations synchrones. Nous etudions egalement c’est quoi un reseau des composants RA2DL au niveau d’une application distribuee avec la proposition et la modelisation d’un modele d’execution et d’un reseau de RA2DL distribue. Un simple exemple sera mis en place pour comprendre les contributions de ce chapitre.
– Chapitre 5 : propose une approche de securisation du composant RA2DL. Cette approche tient compte du groupement des composants RA2DL dans un conteneur intitule
RA2DL P ool en fournissant deux mecanismes de securit pour chaque P ool : authenti-cation et contr^ole d’acces.
– Chapitre 6 : consacre a l’implementation du composant RA2DL. Le composant s’appuie sur un outil RA2DL T ool pour simuler l’execution et les fonctionnalites de recon gurations de la speci cation a l’implementation de RA2DL. Pour montrer les va-rietes d’applications, nous presentons trois etudes de cas sur lesquelles nous appliquons les contributions inventees au niveau de cette these. Nous montrons en particulier l’uti-lite et les gains de l’approche de recon guration proposee d’AADL par des evaluations statistiques.
– Chapitre 7 : nous concluons la these par un recapitulatif des contributions et des discussions avec des perspectives et des extensions possibles pour montrer l’utilite de notre approche dans nos futurs travaux de recherche.

Ingenierie Dirigee par les Modeles et la Validation

Nous exposons dans cette section l’inter^et de l’ingenierie dirigee par les modeles IDM pour tirer pro t de certains aspects : IDM en faveur de la qualite et de l’adequation des ateliers produits par rapport au besoin, mais aussi pour couvrir le plus largement possible les besoins en termes de veri cation et de validation.

Ingenierie Dirigee par les Modeles

L’ingenierie dirigee par les modeles IDM (en anglais, MDE : Model Driven Engineering) est un concept qui designe la generalisation de l’approche MDA (Model Driven Architec-ture) [Sch06] et la separation ente les speci cations fonctionnelles d’un systeme structure en modeles et les speci cations de son implementation sur une plate-forme donnee. Les avantages de l’IDM sont tres nombreux dans la communaute des systemes informatiques tels que :

| Une meilleure ma^trise de la complexit croissante des systemes informatiques et leur reutilisation,

| La realisation du m^eme modele sur plusieurs plates-formes gr^ace a des projections standardisees,

| L’independance vis a vis des evolutions technologiques,

| L’interoperabilit des applications tout en permettant l’evolution des plates-formes et techniques,

| La mise en uvre de l’IDM est entierement basee sur les modeles et leur transfor-mation. L’approche IDM consiste a manipuler di erents modeles de l’application, depuis une description abstraite jusqu’a une representation correspondant a l’implementation e ective du systeme. Le processus IDM se decompose en trois etapes, represent par la Figure 2.1 :

– Modele Abstrait : ce modele est ra ne a n d’ajouter di erentes informations non fonctionnelles demeurant independantes de la plateforme d’execution qui sera e ectivement utilisee telle que la gestion de la securite,

– Modele Concret : ce modele prend en compte les speci cations propres a la pla-teforme d’execution, il peut ^etre egalement ra ne a n de prendre en compte di erents parametres lies a l’environnement d’execution,

– Application et executif : le modele concret est ensuite utilise pour generer une application executable basee sur les speci cations a partir desquelles le modele abstrait est construit.

L’IDM propose une demarche integree permettant de rassembler tous les elements pour la description d’une application. De cette facon, IDM vise la mise en place de di erentes etapes de ra nement depuis la conception de l’application jusqu’a la production de code executable.

Dans le contexte de l’IDM, les modeles sont manipules via l’utilisation de langages [Pla12]. C’est pourquoi un certain nombre de langages permettant cette description sont apparus et o rent a ce jour un certain nombre de fonctionnalites. La plupart des approches guidees par des modeles se basent soit sur :

| UML (Uni ed Modeling Language) [MG00] c’est un langage de modelisation uni e a usage general avec des pro ls comme MARTE (Modeling and Analysis of Real-Time and Embedded) [Mal08],

| ADL (Architecture Description Language)[ZFZ10] c’est un langage de description d’architecture dedi a des domaines particuliers, il permet la modelisation d’une architecture conceptuelle d’un systeme logiciel et/ou materiel et fournit une syntaxe concrete et une structure generique (framework) conceptuelle pour caracteriser les architectures. Parmi les ADLs, le langage d’analyse et de description d’architectures (Architecture Analysis and Design Language) AADL fournit une notation textuelle et graphique standardisee pour decrire des architectures materielles et logicielles. Le succes d’AADL dans l’industrie est justi e par son support avance a la fois pour la modelisation d’architectures recon gurables et pour la conduite d’analyses. En particulier, le langage a et concu pour ^etre extensible a n de permettre des analyses qui ne sont pas realisables avec le langage de base. Dans cette optique,

une annexe au standard AADL a et de nie ABS (Annex Behavior Speci cation) [BF+07] pour completer les descriptions d’architecture avec du comportement,

| BIP (Behavior Interaction Priority)[BBS06] : c’est un langage speci que pour re-pondre a des besoins particuliers de modelisation et d’analyse, par exemple Fractal [BCL+06] et Ptolemy [EJL+03].

Veri cation et Validation

L’enjeu technologique et scienti que est l’etude de methodes et outils facilitant le deve-loppement rigoureux et a co^ut ma^trise des systemes embarques. La veri cation represente un souci majeur pour un grand nombre de systemes embarques. D’ou l’importance de la validation de ces systemes [DPDP11], c’est-a-dire test, veri cation et certi cation. Il y a donc un besoin reel et pressant de developper des methodes et outils e caces pour la va-lidation des systemes embarques. Car la moindre faille sera exploitee par des malveillants potentiels . Les de nitions les plus adequates selon [TDH+04], [Car02] et [Mac05] pour les termes de veri cation et de validation sont :

– veri cation : est un ensemble d’etapes qui permet d’assurer que les modeles sont correctement formes et developpes selon les bonnes pratiques. Les pratiques a ce niveau peuvent ^etre l’aboutissement d’un ensemble de techniques comme la technique de modeli-sation.

{ validation : est un processus qui permet d’a rmer que le modele est coherent par rapport a son intention en termes de methodes utilisees et de resultat obtenu ; le but ultime est d’obtenir un modele e cace, c’est-a-dire un modele qui adresse le bon probleme, qui fournit des informations pertinentes sur le systeme modelis et que le modele est nalement reellement utilise.

Exemples de recon gurations et IDM

Dans cette sous-section, nous presentons des exemples les plus proches de notre contexte de travail et qui traitent principalement le developpement des systemes adaptables dans le cadre de l’ingenierie dirigee par les modeles.

MADAM

MADAM (mobility and adaptation-enabling middleware) [FHS+06] est projet qui per-met de fournir aux ingenieurs logiciels des moyens adequats pour developper des applica-tions mobiles adaptatives.

Avec MADAM, le modele du systeme est une composition des composants types. Chaque composant type peut ^etre atomique ou composite. Pour chaque composant type, plusieurs implementations peuvent ^etre de nies. Pour distinguer entre les alternatives d’im-plementations d’un composant dans les modeles d’architecture de MADAM, ils annotent des composants avec des proprietes (properties). Les proprietes sont etroitement liees a des elements de contexte. De cette facon, ils representent les dependances entre les imple-mentations de composants et leurs contextes. Ces dependances sont representees sur des proprietes indicatrices de fonctions (property predictor functions), ces proprietes attribuent des valeurs constantes aux proprietes du composant type a n de faire la liaison entre les implementations du composant et les elements du contexte d’adaptation, cf. gure 3.1. Le middleware automatise la derivation d’une variante d’un contexte speci que a l’execution, c.-a-d. les con gurations sont calculees en cours d’execution. MADAM met l’accent sur tous les elements de l’adaptabilite des systemes, notamment : le contexte, la variabilite, le comportement adaptatif du systeme par rapport a son environ-nement. Cependant, la modelisation des operations de recon guration, les caracteristiques temporelles du systeme et l’analyse temporelle du systeme pour son comportement adap-tatif ne sont pas traitees dans le projet MADAM.

DiVA

DiVA (Dynamic Variability in complex Adaptive systems) [FDB+08] traite la notion de l’adaptabilite des systemes dans une approche IDM en focalisant sur un traitement e cace du nombre de con gurations possibles, qui peut cro^tre de facon exponentielle avec chaque nouvelle dimension de variabilite. Dans cette approche on modelise : le contexte, la variabilite, le comportement adaptatif du systeme par rapport a son environnement. Cependant, la modelisation : des operations de recon guration, les caracteristiques tem-porelles du systeme et l’analyse temporelles du systeme pour son comportement adaptatif, restent des points ouverts non traites dans le projet DiVA.

CEA-Frame

CEA-Frame (Construction and Execution of Adaptable applications) [LSO+07] une approche dediee pour la construction et l’execution des applications recon gurables qui o re principalement :

1- Des methodes de speci cation des variantes d’une application en combinant les techniques d’IDM et la modelisation orientee aspect.

2- Un mappage pour generer les elements du systeme lies a la plateforme a partir de speci cations independant de la plateforme.

CEA-Frame presente une partie pour l’instanciation et l’execution de ses applications. En conclusion, cette approche modelise le contexte, la variabilite du systeme et son com-portement adaptatif, mais ne modelise pas les operations de recon guration et ne prends pas en compte l’in uence de ces operations sur les caracteristiques temporelles du systeme.

Dans cette section nous avons present des travaux autour du developpement des sys-temes adaptables dans le cadre de l’IDM. Ces travaux ne traitent pas le cas des systemes de contr^oles industriels dans le cadre de l’IDM.

l’IDM de nos jours, ne cesse de faire face a des applications de plus en plus complexes qui doivent evoluer rapidement, a moindre frais ainsi que dans des courts delais. Et ce en repondant aux exigences croissantes des utilisateurs et au nombre grandissant de fonc-tionnalites a integrer jusqu’a l’obtention du produit nal. Pour aider les developpeurs a suivre cette evolution, de nouvelles techniques de construction de logiciels destinees a faire face a ces contraintes ont vu le jour. C’est le cas de l’approche par composants, qui vise a faciliter le developpement d’applications a partir de l’assemblage de briques logicielles/ materielles prede nies appelees composants. Nous expliquons dans la section suivante les inter^ets des approches par composants.

Le rapport de stage ou le pfe est un document d’analyse, de synthèse et d’évaluation de votre apprentissage, c’est pour cela chatpfe.com propose le téléchargement des modèles complet de projet de fin d’étude, rapport de stage, mémoire, pfe, thèse, pour connaître la méthodologie à avoir et savoir comment construire les parties d’un projet de fin d’étude.

Table des matières

I Introduction G´en´erale
1 Introduction G´en´erale
1.1 Rappels des concepts fondamentaux
1.2 Probl´ematique
1.2.1 D´etection des besoins de reconfiguration
1.2.2 V´erification formelle du comportement
1.2.3 Communication et synchronisation des composants reconfigurables
1.2.4 S´ecurit´e des composants reconfigurables
1.3 Contraintes de Reconfiguration
1.4 Objectif et approche
1.4.1 Objectif
1.4.2 Approche Propos´ee
1.5 Organisation du Manuscrit
II Etat de l’art
2 Etat de l’Art
2.1 Introduction
2.2 Syst`eme de Contr^ole Industriel
2.3 Ing´enierie Dirig´ee par les Mod`eles et la Validation
2.3.1 Ing´enierie Dirig´ee par les Mod`eles
2.3.2 V´erification et Validation
2.3.3 Exemples de reconfigurations et IDM
2.4 Approches par Composants
2.4.1 Concept du Composant
2.4.2 Composants des syst`emes embarqu´es
2.4.3 Composant On-line
2.4.4 Composant Off-line
2.4.5 S´ecurit´e des Approches par Composants
2.4.6 V´erification Formelle par Model-Checking
2.4.7 Synth`ese
2.5 Langage de Description et d’Analyse d’Architectures (AADL)
2.5.1 Principes du Langage
2.5.2 D´efinition des Composants AADL
2.5.3 Structure Interne des Composants AADL
2.5.4 Ports d’interface
2.5.5 Outils AADL Existants
2.5.6 Annexe d’AADL
2.5.7 L’annexe de gestion des erreurs en AADL
2.5.8 Les Modes et les transitions de mode en AADL
2.5.9 Discussion
2.6 M´ethodes de Reconfigurations Existantes
2.6.1 D´efinition
2.6.2 Reconfiguration Statique
2.6.3 Reconfiguration Dynamique
2.6.4 Reconfiguration Automatique des Syst`emes Temps-R´eels Embarques
2.6.5 Synth`ese
2.7 Limites des Solutions Existantes
2.7.1 Inad´equation avec les Syst`emes de Contr^ole Industriel
2.7.2 Reconfiguration Locale du Composant
2.8 Synth`ese
2.9 Conclusion
III Contributions
3 Premi`ere Contribution : RA2DL : Nouveau Composant AADL Reconfigurable
3.1 Introduction
3.2 Formes de Reconfigurations
3.2.1 Reconfiguration d’Architecture
3.2.2 Reconfiguration de Structure (Composition)
3.2.3 Reconfiguration de Donn´ees
3.3 Architecture de RA2DL
3.3.1 Module d’Entr´ee des Ev´enements (IEM)
3.3.2 Module des Donn´ees (DM)
3.3.3 Module des Algorithmes (ALM)
3.3.4 Module de Sortie des Ev´enements (OEM)
3.4 Formalisation de RA2DL
3.4.1 Niveau Architectural (AL)
3.4.2 Niveau Composition (CL)
3.4.3 Niveau de Donn´ees (DL)
3.4.4 Comportement de RA2DL
3.5 Mod´elisation de RA2DL
3.6 Flexibilit´e de RA2DL
3.7 Exemple
3.8 Conclusion
4 Contribution 2 : Nouveau concept : R´eseau des Composants RA2DL
4.1 Introduction
4.2 R´eseau de RA2DL
4.3 Mod`ele d’Ex´ecution d’un RA2DL
4.3.1 Couche 1 : Middleware de Reconfiguration
4.3.2 Couche 2 : Contr^oleur d’Ex´ecution
4.3.3 Couche 3 : Middleware de Synchronisation
4.4 Mod`ele d’Ex´ecution pour les Architectures RA2DL Distribu´ees
4.4.1 D´efinition
4.4.2 Architecture RA2DL Distribu´ee
4.4.3 Coordination Entre les Composants RA2DL Distribu´es
4.5 Mod´elisation d’un R´eseau de RA2DL
4.5.1 Mod´elisation du Mod`ele d’Ex´ecution
4.5.2 Mod´elisation de la Coordination Entre les Composants RA2DL
4.6 Exemple
4.7 Conclusion
5 Contribution 3 : RA2DL-Pool : Nouvelle Approche pour la S´ecurisation du Composant RA2DL
5.1 Introduction
5.2 RA2DL-Pool : Nouvelle Extension pour la S´ecurit´e du Composant RA2DL
5.2.1 D´efinition de RA2DL-Pool
5.2.2 Architecture de RA2DL-Pool
5.2.3 Architecture S´ecuris´ee `a Base de RA2DL-Pool
5.3 M´ecanismes de S´ecurit´e de RA2DL
5.3.1 M´ecanisme d’Authentification
5.3.2 M´ecanisme de Contr^ole d’Acc`es
5.4 Mod´elisation de RA2DL-Pool
5.5 Conclusion
6 Etude de Cas et Exp´erimentation
6.0.1 Outil RA2DL-Tool
6.1 Etudes de Cas
6.1.1 Syst`eme Radar
6.1.2 IEEE 802.11 Wireless LAN
6.1.3 Syst`eme de surveillance du corps
6.2 Evaluation de RA2DL et synth`ese
6.2.1 Evaluation de RA2DL
6.2.2 Synth`ese
IV Conclusion et perspectives
7 Conclusion et perspectives
7.1 Contributions
7.2 Synth`ese
7.3 Perspectives
Bibliographie