1/31

Jean-Philippe Babau, Julien DeAntoni

jean-philippe.babau@insa-lyon.fr

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

31/31

des questions !!!???

32/31

Discussion