1 / 13

Plate-forme logicielle de reconfiguration dynamique

Plate-forme logicielle de reconfiguration dynamique. Bertil Folliot LIP6 / CNRS, Université Pierre et Marie Curie, Paris 6 Bertil.Folliot@lip6.fr Ce projet est, ou a été, partiellement financé par les projets RNRT Phenix (99S0361),

eli
Télécharger la présentation

Plate-forme logicielle de reconfiguration dynamique

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Plate-forme logiciellede reconfiguration dynamique Bertil Folliot LIP6 / CNRS, Université Pierre et Marie Curie, Paris 6 Bertil.Folliot@lip6.fr Ce projet est, ou a été, partiellement financé par les projets RNRT Phenix (99S0361), France Télécom R&D ISA (001B117), GEMPLUS, Web2Grid Technology, le LIP6 (PLERS 2000) et la communauté européenne (IST COACH-34445) Bertil.Folliot@lip6.fr http://vvm.lip6.fr

  2. Besoins • Logiciels embarqués sont rigides • MultOS, Windows CE, SCP, µCLinux, KVM… • Multiplication des cas particuliers • Qualité de Service, tolérance aux fautes, performances, taille… • Problèmes de maintenance et d’évolution du logicielle • Modification des traitements, ajouts de nouvelles fonctionnalités • Évolution rapide du matériel • loi de Moore valide pour les X prochaines années (?) • PC, PDA, Cartes à puces, étiquettes électroniques

  3. Techniques usuelles • Utilisation de rustines (patch) • Lourd, complexe, limite les modifications possibles • Utilisation d’une machine virtuelle • Applications « portables », code compact, modifiable à la volée • Oui, mais : • f(matériel) ? carte à puce (JavaCard), téléphone (KVM) • f(propriétés) ? persistance (Pjama), temps réel (RT-Java) • f(temps qui passe) ? gestion de crise (FT-Java)

  4. Alors quelle approche ? • Ne pas travailler pour le cas général (en général ca fonctionne bien), mais travailler sur le minimum (KISS) • Extraire la complexité de la solution (système) vers une représentation de haut niveau • Notre solution : Virtualiser la machine virtuelle = MVV • coupe transversale depuis l ’application jusqu’au matériel • ou… comment construire l’environnement d’exécution adaptée à un problème particulier

  5. Solution : les MVVs • Virtualiser la machine virtuelle = MVV • MVV = [MV]V est une plate-forme d'exécution (MV) dans laquelle on construit son environnement d'exécution (appelé MVlet) : langage, API, modules systèmes… • Une MVlet correspond à un domaine d'application • Spécification exécutable de haut-niveau (écrite en langage VVM) • Chargeable/déchargeable dynamiquement • Vérification des propriétés • Un mécanisme d'exécution au sein de la MVV pour toutes les MVlets • Environnement d’exécution « actif »

  6. Environnement d'exécution actif • Mise à jour de la plate-forme à la volée • Délocalisation des fonctionnalités • Interopérabilité extrême • échanges de données et de fonctionnalités (même pour des application écrites dans différents langages) • applets, agents • Le (difficile) travail de construire l'environnement d'exécution, n'est fait qu'une fois pour un domaine • optimisation agressive, spécialisation dynamique • Facilité de programmation (langage de haut niveau et services systèmes dédiés au problème à résoudre) : • réduction du temps de mise sur le marché, • pas de langage de programmation unique.

  7. Application au satellite COROT(COnvection, ROtation et Transits planétaires) • Asterosismologie et recherche d'exoplanètes (Observatoire de Paris / CNRS - CNES)

  8. Problèmes de l’embarqué satellitaire • Impact de protons • Durée de vie • La mission scientifique est basée sur des hypothèses théoriques non vérifiées • Projet PLERS : reconfiguration logiciel pour satellite. Contraintes : • Sécurité • Réversibilité des reconfigurations • Cycle efficace 90% du CPU pendant 5 jours (+ perte du CPU pendant 10mn = 2 jours pour recalibrer) • Débit: 140kbit/jour vers le satellite, non interactif (500Mbit/jour vers le segment sol)

  9. Reconfiguration de logiciels embarquées • Décomposition du logiciel en 2 parties (reconfigurable ou non) LOGIQUE METIER (!) • Définition des interfaces • tâches, ports de communication, synchronisations • Réalisation d’un intergiciel ad-hoc Busard • Noyau temps-réel Thread-x • CURL - langage de description de configuration (et de reconfiguration) • Interpréteur de configuration (au sol et embarqué) • (+ le problème de la vérification d’une configuration + le respect des contraintes temps réelles)

  10. MVV CURL Applications COROT 6 7 5 MVV CURL Applications COROT 2 3 4 Configuration souhaitée Parser/ Compilateur Vérification de la nouvelle configuration Script (CURL) 1 Chaîne de commande/contrôle Station sol Configuration actuelle

  11. Conclusion • Construction d’un environnement d’exécution spécifiquement adapté à son domaine d’application • embarqué satelitaire, cartes à puces, téléphones mobiles… • réseaux actifs, caches web, intergiciels… • Adaptable/spécialisable dynamiquement tout en restant interopérable avec l’existant

  12. Questions ?

  13. My appli (type SuperVM) (something to do) "SuperVM" "SuperVM" Application loader "SuperVM" My SuperVMlet (define-instruction ()) (define-object ()) (define-syntax ()) (define-primitives ()) (define-loader ()) (use-os-module ()) VMlet loader Execution engine - Virtual processor Object memory VVM Architecture de la MVV µ-VM {OS,ø} {CPU, memory, I/O}

More Related