Architectures logicielles pour les systèmes embarqués ... · – Organisation du système ......
Transcript of Architectures logicielles pour les systèmes embarqués ... · – Organisation du système ......
1/31
Jean-Philippe Babau, Julien DeAntoni
Architectures logiciellespour les systèmes embarqués temps réel
ETR’07 4 septembre 2007
2/31
Architectures logicielles pour les systèmes embarqués– Modèles à composants– Langages et formalisation– Mise en œuvre
Style architectural– Qinna : gestion dynamique de contrats de QoS– Déploiement– SAIA : indépendance vis-à-vis des entrées/sorties
Conclusion
Plan
3/31
Les spécificités des systèmes embarqués temps réel
Systèmes fortement contraints– Contraintes temporelles– Contraintes d’embarquabilité
Sûreté de fonctionnement– Systèmes critiques– Systèmes enfouis
Développement– Ressources limitées et spécifiques– Systèmes prédictibles– Systèmes dédiés
Importance de l’implémentation pour respecter les contraintes
4/31
Principes généraux des architectures– Organisation du système– Structure gros grain, « programming in the large »– Une application = un assemblage de composants , soit une configuration
Améliorer la maîtrise du développement– Séparation des préoccupations
• Aide au choix dans le découpage d’un problème en sous-problèmes• Masquage de détails non pertinents à un haut niveau d’analyse• Détection et isolement de parties défaillantes
– Qualité accrue attendue : réutilisation, interopérabilité, documentation
Assurer la correction des architectures : analyse de performances– Approche analytique (RMA)– Simulation exhaustive, preuves– Simulation
Les architectures
5/31
Architecture logicielle à composants
Modèle de programmation à composants– Composants– Interfaces– Connecteurs– Niveau de description des configurations
Outils pour la conception– Style architectural– Langages (ADL, UML et modèles)
Mise en oeuvre– Intergiciel ou compilation
Validation
6/31
Les composants
Composant : brique de base– Primaire et/ou composite– Comportement
• Spécification de haut niveau• Code exécutable, code interprétable ou compilable• Abstraction du code
• Comportement temporel (durées, …)
• Propriétés extra fonctionnelles du code (nom d’auteur, numéro de version, …)• Dépendances du code (librairies, …)
Choix d’une description– Guidée par l’objectif : déploiement, composition, analyse– Combinaison de plusieurs descriptions– Assurer la cohérence des vues
• aspects temporels : WCET ou WRT ? Budgets temporels ?
7/31
Les interfaces
Interface : permet d’accéder aux comportements du composant– Rôle : fonctionnel ou configuration ou synchronisation– (Flot de données/controle et Entrée / Sortie) Vs (client/serveur (opération) et Fournis / Requis)– Appel bloquant Vs appel asynchrone– Spécification comportementale
Contrats– Niveau 1 : signature de l’appel– Niveau 2 : comportement (pré / post condition sur les paramètres d’appel)– Niveau 3 : protocole d’appel
• Toujours open() avant read()– Niveau 4 (QoS) : contraintes quantifiées et/ou temporisées
• Nombre d’appels• Fréquence d’appel• Retards, échéances
Niveau de description– Composition (CBSE) : tout est contractualisé (fourni/requis) au niveau des interfaces– Assemblage : tout est spécifié au niveau des interfaces et des composants
8/31
Les connecteurs
Connecteurs : spécifier les communications entre les interfaces– Lien logique
• Fil entre interfaces homogènes– Connecteur complexe
• Comportement• Pour lier des interfaces hétérogènes• Adapter des contrats
• Programmable ou configurable• Composant simple ou composite• Librairies prédéfinies• Langage spécifique
Contrats– Établissement à la connexion– QoS rarement traité au niveau du connecteur
9/31
Embarqué temps réel– Architecture technique
• Souvent fixée : processeur, RTOS, synchrone, …• Pas toujours explicitée
– Architecture logique• Budget temporel ou performances inconnues
– Déploiement• Généralement fixé
– Architecture opérationnelle• ≈ architecture logique• Temps mesurés• Analyses de performance
Aspect essentiel– Intégration dans le processus de développement– Sémantique du temps Vs Abstraction de l’architecture technique
Niveau de description de la configuration
Machine/exécutif/code
Architecturelogique
Architecturetechnique
V V
V
V V
Architecture opérationnelle
Déploiement
ImplémentationV
V
10/31
Langages
ADL : langage de description d’architectures– Outil de description d’assemblages– Graphique / textuel, informel / formel
UML– Standard de modélisation– ADL : UML2, profil UML
Modèles (IDM ou MDE)– Concepts, liens entre les concepts
• Modèles, méta-modèles, transformations de modèles– MOF, eCore– Outils : éditeurs, transformations de modèles, …
11/31
Style architectural
Bonnes pratiques– Types de composants et de connecteurs, contraintes d’assemblage– ≠ ADL– ≠ design pattern qui est la solution à un problème– ≈ pattern qui est un motif que l’on retrouve souvent– Modèle minimal pour appliquer le style
Objectif qualitatif– Propriété de qualité suite à l’application du style architectural– Style en couche : faible couplage, indépendance vis-à-vis d’une plateforme– Domaines des IHM : PAC, Modèle / vue / contrôleur : réutilisation du contrôle
Objectif quantitatif– L’application du style assure que la propriété pourra être évaluée– Tâches périodiques indépendantes : analyse RMA possible
12/31
Mise en oeuvre
Intergiciel– Composants et/ou connecteurs– Identifiable à l’exécution– Gestion dynamique
• Installation / désinstallation• Modification d’un composant• Adaptation au contexte
Compilation– Pas de composants à l’exécution– Adapté aux systèmes critiques non évolutifs
Librairies– Mises en œuvre d’un style architectural
13/31
Validation
Propriétés– Non chiffrables (qualité logicielle) Vs chiffrables (sécurité, QoS)– Composables (mémoire) Vs émergentes (échéance)
Propriétés temporelles– Temps logique (sûreté, vivacité)
• Composition de propriétés– Temps physique
• Analyse par morceaux« analyse ordonnançabilité monoprocesseur puis analyse bout en bout »• Problématique complexe de la dérivation de contraintes temporelles
Sémantique opérationnelle temporisée– RdP, UPPAAL, Kronos, IF, …
14/31
Architecture logicielle à composants
Modèle de programmation à composants– Composants, interfaces, connecteurs– Niveau de description des configurations
Outils pour la conception– Style architectural– Langages (ADL, UML et modèles)
Mise en oeuvre– Intergiciel ou compilation
Validation
Méthodes
15/31
Systèmes embarqués communicants– Ajout / retrait de composants– Système adaptable (applications, ressources)– Gestion sure des ressources
Composants à l’exécution– Architecture opérationnelle
Gestion de contrats de niveau 4 (contraintes quantifiées et/ou temporisées)
Qinna : un style architectural pour la gestiondynamique de la qualité de service
Video Decoplay decode decode
25 i/sec 25 i/secBONContrat de QoS
Contrat fonct.
16/31
Modèle de composants Fractal de France Télécom R&D– Tout est composant– Interface : services fournis et requis– Connecteur : fil logique– Composition : basée sur les contrats
• Signature / pré-post / protocole / Qualité de Service– Établissement du contrat à la connexion
Mise en oeuvre– Think : implémentation C de Fractal pour l’embarqué– Gestion dynamique des composants à l’exécution
Modèle de composants
Video Decoplay decode decode
25 i/sec 25 i/secBONContrat de QoS
Contrat fonct.
17/31
QoS– Comportement : discrétisation par mode de fonctionnement (configuration locale)– Contrats sur les interfaces en terme de QoS fournie / requise
• Niveau de QoS contractualisé• Enveloppes de QoS
Gestion des contrats ou négociation– Gestion dynamique : tout changement entraîne une recherche de solution– Composants pour l’établissement, le suivi et l’adaptation
Séparation des préoccupation– F-Component, QoSComponent, QoSBroker, QoSManager, QoSDomain, QoSObserver
Généricité– types abstraits
Composants et QoS
18/31
Table de mapping par service et par composant– Établie a priori
• Discrétisation des niveaux• Compromis granularité / nombre d’opérations
– Établissement d’un contrat :recherche du niveau de contractualisation maximal vis-à-vis de QoSRequises possibles
Comportement
LentMoyenRapide
QoS fournie
111
QoSLocaleRequise
321
Niveau decontractualisation
QoSServiceRequis
ContrainteLocale
10% CPU220% CPU440% CPU10
19/31
Composants pour la gestion des contrats
QoSDomain
QoSComponentManager
QoSComponentBroker
QoSComponent1..N
1
1
1..N
11
1..N
11
0..N
Composant à gérer du point de vue QoS
Test d’admission,Réservation
Mapping,MécanismesAdaptation,
Maintenance
Politiques adaptation,maintenance
QoSComponentObserver0..N
0..1
PolitiqueObservation
Applicatif (Video)Service (Decodeur)OS (Thread)Ressource (Memoire, CPU)
20/31
Gestion dynamique de la QoS
Suivi des contrats– Changement
• Demande / Arrêt d’un F-component• Modification : demande d’une application ou état d’une ressource
– Recherche d’un contrat acceptable• Parcours de l’arbre défini par les QoSManager• Test d’admission par appel des QoSBrokers
Bilan– Compromis gaspillage de QoS / adaptations– Confiance
• Contrôle de ce qui est alloué par le QoSComponent : niveau ressources
– Impact de la période d’observation en terme de retards
21/31
Etudes de cas– Ordonnancement
• Structures hiérarchiques, régisseur
– Pic de demande, de charge• « saut(s) » selon la forme du pic, suivi périodique
– Variation d’une ressource• « Marches » prédéfinies, suivi événementiel
– Application vidéo• 7 QoSComponent, processeur 200Mhz, 60 Mo de RAM• Établissement et adaptation d’un contrat : 4,38 ms et 1,08 ms• Place : 749 ko, 1,5 %
Utilisation– Systèmes multimédias
• Adaptation, coûts raisonnables
– Systèmes temps réel• Structuration et intégration des politiques de gestion de la QoS
Evaluation de Qinna
22/31
Expérimentations et validation
• ARA de l’ANR : REVE– Architecture à composants pour l’adaptation aux changements de contexte– Contexte
• Etat des ressources• Plateforme d’exécution
• Mise en place de librairies– Application à un viewer d’images distantes– Librairies
• C++, IF– Validation
• Taux d’utilisation des ressources• Nombres d’opérations d’adaptation
23/31
Motif pour le déploiement
architectureapplicative nArchitecture
technique
mapping
Architecture n+1V
Architecturetechniquevirtuelle
VV
Approche MDA à base de composants– Plate-forme : PM+PIM+mapping -> PSM– Plateforme abstraite– Structuration à base de composants– sémantique (IF), méta-modèles– Par étape : E/S, communications, concurrence
V
V
24/31
Indépendance vis-à-vis des mécanismes d’entrée/sortie– Simulation/prototypage– Portabilité sur cibles diverses– Prise en compte de modifications (E/S, fonction)– Respect de contraintes de QoS applicative
Modèles de composants– Comportement : automate temporisé– Interfaces : flots d’information en entrées / sorties– Niveau de description
• Architecture logique
Style architectural SAIA(Sensor Actuator Independant Architecture)
SAIModel
SAModel
ALM
SASM
control
25/31
Style architectural SAIA(Sensor Actuator Independant Architecture)
Principes– Architecture en couches– Plate forme abstraite (QoS aware)– Type de composants et contraintes d’assemblage– Défini par un métamodèle
• Modèle de QoS pour les flots d’information
Eléments de SAIA– SAIM : capteurs / actionneurs abstraits + loi de contrôle– SAM : capteurs / actionneurs réels ou émulés– ALM : connecteur complexe
• Formatage, interprétation, adaptation de QoS
SAIModel
SAModel
ALMcontrol
26/31
Contractualisation de la QoS
Sémantique opérationnelle temporisée– comportement (interprétation, fusion, adaptation, …), WCET, retard– IF
Evaluation de la QoS– SAM + ALM : assemblage : observateurs– ALM / SAIM : connexion : relation de satisfaction
QoS Fournie (ALM) « satisfait » QoS Requise (SAIM)– Intervalles : inclusion– LTS : la QoS requise simule la QoS fournie
SAIModel
SAModel
ALMcontrol
QoSfournie
QoSrequise
satisfait
27/31
Expérimentations de SAIA
Outil basé sur GME Méthode de mise en oeuvre
Concours– Runner Up of the maRTian Task design compétition, 4ème Cibermouse challenge– Implémentation efficace
• Mise en place des taches selon une stratégie événementielle
Maîtrise de la conception– Réutilisation de modèles du SAIM– Identification des composants
Validation des contrats de QoS– Outil de mise au point des paramètres de QoS
Déploiement correct sur cible réelle
28/31
MDA et communications
Architecture d’un objet communicant– Communication distante entre objets « A remoteSend to B »
« Abstract Platform »– Famille des protocoles
• wireless / connexion oriented– QoS générique
« Concrete Platform »– Irda / Bluetooth
« Mapping »– Aspect fonctionnel : lien logique– QoS : dérivation de contraintes, test d’admission, négociation
AbstractCommunication
PlatformIrDAPlatform
Mapping
Communicatingapplication
application
29/31
Modèle de composants– Définir les concepts de base pour le domaine visé– Sémantique opérationnelle temporisée
Langages et modèles– Unifier et relier les concepts par domaine / entre les domaines
Styles architecturaux– Définition de règles de structuration : configuration analysable et de qualité
Mise en œuvre– Intégration de la concurrence lors du déploiement (tâches, ordonnancement)– Abstraction de l’architecture technique– Solutions hétérogènes : compilation + intergiciel
Conclusion sur les architectures
30/31
Méthodes de mise en place des architectures– Définition d’étapes, liste de « bonnes questions », règles informelles– Outils d’aide à la décision guidée par la performance
Contrat de QoS (niveau 4)– Intégration des propriétés émergentes– Hétérogénéité à la connexion
• SAIA : établie par construction d’un connecteur complexe (assemblage)• Qinna : négociation à l’exécution• Communications : négociation et configuration à l’exécution
– Enveloppes de QoS
Conclusion sur les architectures